%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%													%
%			Mit LuaLaTeX setzen, wegen Schriftart !!!!			%
%			Schriftart "Cantarell" von squirrelfonts.org			%				
%													%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



\documentclass[
				%twocolumn,
				twoside=true,
				headsepline,
				footsepline
				]{scrartcl} % scrreprt
\usepackage{../grubyware-style}
\usepackage{blindtext}
%\providecommand{\bashinline}[1]{\lstinline[style=bash-inline] !#1!  }	
\begin{document}
	\thispagestyle{scrplain}
	\titlehead{{\Large Fachhochschule Kaiserslautern 
		\hfill WS-2010/2011\\}
		Fachschaft Informatik und Mikrosystemtechnik\\
		Amerikastraße 1\\
		66482 Zweibrücken}
	\subject{Tutorial}
	\title{Plattform zur Projektverwaltung mit \emph{Ruby on Rails 3.0}}
	\subtitle{Informatikprojekt Phase II}
	\author[]{Simon Barth} \author[]{Andreas Baur} \author[]{Sven Kuntz} \author[]{Roland Staud}
	\affil{}
	\publishers{Betreut durch Prof. Dr. Hettel}
	\maketitle
	\begin{abstract}
		Dieser Artikel wurde im Rahmen einer Projektarbeit an der FH Kaiserslautern für 
		Studenten der Informatik erstellt. Er befasst sich mit den am MVC-Modell orientierten
		Elementen des \emph{Ruby on Rails} Frameworks. Es wird die Planung und Entwicklung
		einer Plattform zur Projektverwaltung beschrieben. 
	\end{abstract}
	\setcounter{page}{1}
	\tableofcontents
		
	\newpage
	\section{Motivation}
	\subsection{Wahl der Technologie}
	Die Realisierung einer Plattform, die die rudimentäre Planung von Softwareprojekten ermöglichen soll, ist ein recht komplexes Thema für ein studentisches Projekt mit einem Zeitraum von gerade einmal elf Wochen.\\
	Nachdem das Ziel des Projektes fest stand, stand die Frage der verwendeten Technologien für die Realisierung noch aus. Eine derartige Web-Applikation schnell und effektiv zu realisieren, würde mit Hilfe bereits in der Vergangenheit verwendeter Technologien, wie zum Beispiel der Java Enterprise Edition einen enormen Implementierungsaufwand bedeuten. \\
	\\
	Bei den folgenden Recherchen kam man immer wieder schnell auf das ''Ruby on Rails''- Framework. Auf den ersten Blick waren hier eine gute Dokumentation, zahlreiche Beispielprojekte, sowie viele Tutorials von engagierten Entwicklern verfügbar, die bei der Realisierung der geplanten Groupware helfen können. \\
	\\
	Rails ist ein sehr junges und sich schnell weiter entwickelndes Framework, wobei Versionssprünge hier oft gravierende Änderungen bedeuten \cite{RoR3Release}.
	
	\subsection{Ziel dieses Tutorials}
	Hier soll ein Überblick über die grundlegenden Mechanismen des ''Ruby on Rails''- Framework gegeben werden und anhand der realisierten Groupware, sowie einfacher Beispiele ein Eindruck vermittelt werden,  wie sich die Entwicklung einer Web-Anwendung auf dieser Technologiebasis ''anfühlt''.
	
	

	\section{Grundlagen}
	Vor der Arbeit mit einer neuen, noch unbekannten Technologie, ist es in der Regel sinnvoll sich eine grundlegende Wissensbasis an zu eigenen. In diesem Kapitel wird kurz auf die verschiedenen Umgebungen eingegangen in denen mit Rails entwickelt werden kann. Weiterhin wird eine kurze Anleitung zum Einrichten einer lauffähigen Entwicklungsumgebung unter Windows sowie unter unixoide Systemen wie z.B. Mac OS X oder Linux gegeben. \\
	Anschliessend folgt ein Überblick über die grundlegende Struktur einer "Ruby on Rails''-Applikation und wie mit Hilfe der im Framework integrierten Werkzeuge \\schnell erste Ergebnisse erzielt werden können.
	\subsection{Konventionen}
	In diesem Tutorial werden die folgenden Darstellungskonventionen verwendet:\\
	\begin{itemize}
		\item \emph{Eigennamen}
		\item \path{Dateinamen_und_Pfade}
		\item Konsolenbefehle:\\
			\bashinline{Konsolenbefehle im Text}
	\begin{lstlisting}[style=bash]
	Konsolenbefehl 1
	Konsolenbefehl 2
	Konsolenbefehl 3
	...
	\end{lstlisting}
		\item Programmierbeispiele: 
	\begin{lstlisting}[style=paper]
	def ruby_beispiel
		# Kommentar
		beispiel = 1
		string = "Hallo Welt !"
	end
	\end{lstlisting}
	\end{itemize}
	
	\subsection{Ruby}
	\emph{Ruby} ist ein interpretierte Programmiersprache die Mitte der neunziger Jahre in Japan erfunden wurde. 
	"Ruby on Rails'' ist, wie der Name schon sagt, ein Framework das in Ruby geschrieben wurde. In diesem Tutorial wird davon ausgegangen, dass der Leser \emph{Ruby} beherrscht. Falls die nötige Erfahrung im Umgang mit \emph{Ruby} noch nicht vorhanden ist, ist unter den vielen im WWW verfügbaren Ressourcen das Ruby-Buch von Author Jeremy McAnally zu empfehlen \cite{Ruby}.
	
	\subsection{Werkzeuge}
		Eine funktionsfähige Umgebung für die Entwicklung mit Ruby on Rails lässt sich auf jeder gängigen Plattform erzeugen. Im Folgenden wird gezeigt wie Ruby auf einem Mac OS X, Windows- oder Linux-System lauffähig installiert wird, sowie eine Übersicht über gängige Entwicklungsumgebungen und Editoren in Verbindung mit der Konsole gegeben.
		\subsubsection{Rails-Umgebung}
		\minisec{Windows}
		Um den Ruby-Interpreter zu installieren benötigt man die Installationsdatei von \url{www.ruby-forge.org/projects/rubyinstaller}. Hierbei sollte die Umgebungsvariable \bashinline{PATH} gesetzt werden, sowie alle \path{.rb} und \path{.rbw} Dateien mit der Ruby-Installation verknüpft werden, wie in Abbildung \ref{img:ruby_installer1} gezeigt.
		
		\begin{figure}[ht]
		\includegraphics{./img/ruby_installer1.png}
		\caption{Rubyinstaller}
		\label{img:ruby_installer1}
		\end{figure}

		Neben dem Interpreter wird noch die Ruby-Paketverwaltung \emph{Gem} benötigt, welche unter \url{http://rubyforge.org/projects/rubygems} heruntergeladen werden kann. \\
		Nach der Installation kann \emph{Gem} von der Kommandozeile aus aufgerufen werden. Um zu überprüfen, ob die Installation erfolgreich verlaufen ist, kann auf der Komandozeile der Befehl \bashinline{gem} eingegeben  werden, worauf eine Ausgabe wie in Abbildung \ref{img:gem_kontrolle}  erfolgt.
		
		\begin{figure}[ht]
		\includegraphics{./img/gem_kontrolle.png}
		\caption{Ausgabe von gem}
		\label{img:gem_kontrolle}
		\end{figure}
		
		Nun kann über den Befehl \bashinline{gem install rails} das \emph{Ruby on Rails} Framework installiert werden. Damit ist die Installation abgeschlossen.
		
		\minisec{OS X und *nix}
		Unter OS X und Linux wird \emph{Ruby} über \emph{RVM} installiert. Dazu muss auf der Konsole folgende Zeile eingegeben werden:
		\begin{lstlisting}[style=bash]
			bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
		\end{lstlisting}
		
		Anschließend wird \bashinline{[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"} in die Datei \path{.bashrc} im Heimatverzeichnis des Benutzers eingetragen. Nach einem Neustart des Konsolenfensters kann mit \bashinline{rvm install ruby-1.9.2} die neuste Rubyversion installiert werden, welche in diesem Tutorial verwendet wird. Danach sollte diese Version noch mit \bashinline{rvm use ruby-1.9.2 --default} zum Standard gemacht werden. Nun kann über den Befehl \bashinline{gem install rails} das \emph{Ruby on Rails} Framework installiert werden. Damit ist die Installation abgeschlossen.
		
		\subsubsection{Entwicklungsumgebungen und Editoren}
		Grundsätzlich gibt es zwei Möglichkeiten mit \emph{Ruby on Rails} zu Entwickeln. Auf der einen Seite stehen kostenlose Entwicklungsumgebungen wie NetBeans oder Eclipse zur Verfügung, wobei auch kommerzielle Produkte wie beispielsweise RubyMine erhältlich sind. Dem gegenüber wird auch oft mit einer Kombination aus Editor und Konsole gearbeitet. Als Editor empfehlen sich Notepad++, Gvim bzw. MacVim oder auch der kostenpflichtige TextMate.

	\subsection{Aufbau}
	Rails-Applikationen besitzen eine fest vorgegebene Struktur, die dem \emph{MVC-Pattern} entspricht. 
		\subsubsection{MVC-Muster}\label{chapter:mvc}
		Das MVC-Muster ist ein Architekturmuster zur Strukturierung von 
	Software in drei Einheiten: \emph{model}, \emph{view} und \emph{controller}. Durch ein MVC-Muster wird ein flexibler Programmentwurf gewährleistet, der spätere Änderungen oder Erweiterungen erleichtert und die Wiederverwendbarkeit einzelner Komponenten ermöglicht. Eine grafische Übersicht über das MVC-Muster ist in Abbildung \ref{img:rails_mvc} zu sehen. Die Abbildung zeigt auch, wie der Weg einer Benutzeraktion vom Browser zur Datenbank ist, und wie die Daten wieder zum Browser gelangen.
	
		\begin{figure}[ht]
		\includegraphics{./img/rails_mvc.png}
		\caption{Das MVC-Pattern in Ruby on Rails}
		\label{img:rails_mvc}
		\end{figure}
		
	\paragraph{Das Modell, \emph{model}}
		enthält alle darzustellenden Daten und je nach Implementierung
		auch die Geschäftslogik. Es ist unabhängig von Präsentation und Steuerung.
	\paragraph{Die Präsentation, \emph{view}}
		ist für die Darstellung der benötigten Daten aus dem Modell
		und die Entgegennahme von Benutzerinteraktion zuständig. Sie kennt ihre
		Steuerung und das Modell, dessen Daten sie präsentiert. Für eine Weiterverarbeitung 
		übergebener Daten vom Benutzer ist sie allerdings nicht zuständig. Zu jeder
		Präsentation existiert ein Modell.
	\paragraph{Die Steuerung, \emph{controller}}
		verwaltet Präsentationen, nimmt Benutzeraktionen von ihnen
		entgegen, wertet diese aus und agiert entsprechend. Die Steuerung soll keine
		Daten manipulieren, sie entscheidet lediglich aufgrund eingetroffener Benutzeraktionen
		aus der Präsentation, welche Daten im Modell geändert werden müssen.
		Sie enthält ebenfalls Mechanismen, mit der Benutzerinteraktionen der Präsentation
		beschränkt werden können.
	\paragraph{Das Routing, \emph{router}}
		Das Routing-System von Rails untersucht die URL eines eintreffenden Requests
		und entscheidet welche Aktion von der Applikation ausgeführt werden soll.
		Das Thema \emph{Routing} wird in Kapitel \ref{chapter:routing} vertieft.
		
		\subsubsection{Struktur eines Rails-Projekt}\label{chapter:structure}
			\paragraph{Ordnerstruktur}
			Jedes Rails-Projekt hat eine fest vorgegebene Datei-Struktur.%, welche in Abbildung \ref{img:projektstruktur} zu sehen ist.
			Die für dieses Tutorial wichtigsten Ordner sind \path{app}, \path{config}, \path{db}	und \path{public}.\\
			Im \path{app}-Ordner befinden sich die Ordner \path{controllers}, \path{helpers}, \path{models} und \path{views} in denen sich, wie die Namen schon sagen, die \emph{Controller}, \emph{Helper}, \emph{Models} und \emph{Views} befinden.\\
			Im \path{config}-Ordner befinden sich Dateien zum Einrichten der Datenbankverbindung und unter anderem auch die \path{routes.rb}, die in diesem Tutorial noch eine große Rolle spielen wird.\\
			Im Ordner \path{db} befindet sich das Datenbank-Schema, sowie die dazu gehörigen Migrationen. Was eine Migration ist, wird in Kapitel \ref{chapter:activerecord:migration} genauer erklärt.\\
			Unter \path{public} befinden sich alle in der Applikation verwendeten Bilder,  Javascripts, Stylesheets sowie alle statischen HTML-Seiten.
			
			\paragraph{Umgebungen}
			Rails bietet die Möglichkeit mehrere Konfigurationen für eine Applikation zu speichern. Dies wird durch  Umgebungen realisiert. Ein neu generiertes Railsprojekt besitzt drei Umgebungen: development, test und 
			production. Für diese kann eine eigene Datenbank konfiguriert werden, sie besitzen eigene Log-
			Dateien und es können unterschiedliche Paketabhängigkeiten definiert werden.
			
			\paragraph{Konventionen}
			Wie bei Softwareprojeken üblich, sollte man sich auch bei einer Webapplikation, die in
Ruby on Rails geschrieben ist, nicht wiederholen. Das heißt redundanten Code	vermeiden.  Um dies zu gewährleisten gibt es die Helper-Dateien, in denen man für die entsprechenden Views Ruby-Code bereitstellen kann.
\begin{lstlisting}[style=paper]
module BookmarksHelper
	def back_to_list
		link_to "Zurück zur Liste", :action => "index"
	end
end
\end{lstlisting}
			Dann kann in den Bookmark-Views die ''Zurück'' Links durch 
\begin{lstlisting}[style=paper]
<%= back_to_list %>
\end{lstlisting}
			ersetzt werden.\\
			Möchte man eine Methode in mehreren \emph{Controllern} verwenden, so kann man diese im \path{application_controller.rb} ablegen und hat so in allen \path{controllern} darauf Zugriff.\\
			 Die Modellnamen sind dabei jeweils im Singular zu wählen, die Namen der Steuerung im Plural mit angehängtem "controller"\space und die Präsentationen haben eigene Ordner, die ebenfalls im Plural bezeichnet sind. Dadurch erkennt das Routing, auf welche Präsentation und auf welches Modell es bei einer bestimmten Aktion aus der Steuerung zugreifen muss. Hierzu ein kleines Beispiel: \emph{Model} \path{student.rb}, \emph{Controller} \path{students_controller.rb} und der \emph{View}-Ordner \path{students}. Des weiteren sollten bestimmte Dateien immer in die dafür vorgesehenen Ordner abgelegt werden, z.B. alle \path{*.css} Dateien befinden sich im Ordner \path{public/stylesheets}.
			Eine weitere wichtige Konvention ist die Schreibweise der Routings, die man in den \emph{Views} und \emph{Controllern} verwendet. Dies wird in Kapitel \ref{chapter:view} näher erläutert. Diese Konventionen sind zwar nicht
			verpflichtend, man erspart sich jedoch viel Konfiguraitionsaufwand wenn man sie einhält.
		
		\subsubsection{Rails-Werkzeuge}
			Das \emph{Ruby on Rails} Framework kommt mit einigen kleinen Werkzeugen, die einem die Arbeit erleichtern. Diese Werkzeuge werden in diesem Abschnitt 
vorgestellt. Sie werden alle auf der Kommandozeile ausgeführt, wobei manche Entwicklungsumgebungen \emph{Wrapper}  bereitstellen. Dieser Abschnitt stellt einen Überblick über die Werkzeuge dar, ihre Anwendung wird in Kapitel \ref{chapter:einfuehrungsbeispiel} anhand von Beispielen gezeigt.
			\begin{description}
				\item[Generatoren]
					Mit dem \emph{Rails}-Framework lassen sich viele Teile der Applikation generieren. Dies beginnt bereits mit dem Anlegen einer neuen Applikation, wozu der Befehl \bashinline{rails new APPNAME} dient. Wechselt man nun in das neue Verzeichnis APPNAME, so kann man hier weitere Generatoren ausführen.
					Mit \bashinline{rails generate} bzw. \bashinline{rails g}kann man sich eine Übersicht über die Möglichkeiten die zur Verfügung stehen ausgeben lassen. Es werden hauptsächlich die Generatoren für Model, Controller und Scaffolding verwendet.
\bashinline{rails generate model} wird verwendet um Datenobjekte zu erzeugen, \bashinline{rails generate controller} um Controller mit, Helper-Klassen und  zugehörige Views zu erzeugen, und \bashinline{rails generate scaffold} erzeugt sowohl Model als auch Controller mit Helper-Klassen sowie View inklusive Formular zum Erstellen und Bearbeiten neuer Datenobjekte.
				\item[Rails Konsole]
					Die \emph{Rails Konsole} stellt eine interaktive Shell dar, auf der einem alle Klassen, Objekte und Datentypen von \emph{Rails} und der eigenen Applikation zur Verfügung stehen. Aufgerufen wird die \emph{Rails Konsole} entweder mit \bashinline{rails console} oder \bashinline{rails c} im Verzeichnis der Applikation. Falls Änderungen am Code vorgenommen werden empfiehlt es sich die \emph{Rails Konsole} neu zu starten, da man sonst mit einer veralteten Umgebung arbeitet.
				\item[Rails Server] \emph{Ruby on Rails} stellt mit \emph{WEBrick} einen Webserver bereit, mit dem man schnell und einfach seine Applikation im Browser testen kann. Er wird mit \bashinline{rails server} oder \bashinline{rails s} im Applikationsverzeichnis gestartet. Der Server lauscht auf Port 3000. Nach dem Start kann man seine Applikation im Browser unter \url{http://127.0.0.1:3000/APPNAME} bzw. \url{http://localhost:3000/APPNAME} testen.
				\item[Rake-Tasks]
					Zur Automatisierung von Aufgaben steht das Tool \emph{Rake} zur Verfügung. Es ist, wie der Name eventuell schon vermuten	lässt an das Tool \emph{make} angelehnt. Mit \bashinline{rake -T} kann man sich alle zur Verfügung stehenden Aufgaben mit einer kurzen Beschreibung anzeigen lassen. \emph{Rake-Tasks} die häufig verwendet werden sind vor allem  interaktionen mit der Datenbank, wie \bashinline{rake db:migrate} was dazu führt, dass ein Datenbankschema erzeugt wird. In späteren Kapiteln wird der genaue Gebrauch noch deutlicher dargestellt werden.
					
				\item[Bundler]
				Um die Abhängigkeiten der verwendeten \emph{gems} aufzulösen steht \emph{Bundler} bereit. \emph{Gems}
				sind Plugins, Bibliotheken oder eigene Programme, die in Ruby geschrieben sind. Sie können über \emph{Ruby-Gems}, die Ruby-Paketverwaltung installiert werden. Um die Verwaltung der \emph{Gems} eines Projektes zu erleichtern, können diese in die Datei \path{Gemfile} geschrieben werden. Anhand dieser Datei installiert \emph{Bundler} durch den Befehl \bashinline{bundle install} die benötigten Pakete. Im \path{Gemfile} können auch Bedingungen, wie die zu installierende Version angegeben werden. 
				
				\item[Ruby Index]
				Um sich die API-Dokumentationen von Ruby-Programmen anzusehen kann das Konsolenprogramm 
				\bashinline{ri} verwendet werden. Der Aufruf erfolgt nach dem Schema \bashinline{ri [target]}. 
				Target kann dabei eine Klasse, ein Modul oder ein Methode sein.
			\end{description}
			
		\subsection{Routing}\label{chapter:routing}
			\subsubsection{Der Rails-Router}\label{chapter:routing:router}
			Der \emph{Router} stellt die zentrale Komponente der Interaktionssteuerung bei \emph{Ruby on Rails} dar. Wie in Abbildung \ref{img:rails_mvc} in Kapitel \ref{chapter:mvc} gut zu sehen ist, bildet er die Schnittstelle zwischen Interaktionssteuerung und Anfragen des Webbrowsers. Dabei analysiert er die URL eingehender Anfragen und leitet sie entprechend an eine bestimmte \bashinline{action} eines bestimmten Controllers weiter. \\
			\\
			Die Auswahl der entsprechenden \bashinline{action} soll jetzt anhand einiger kleiner Beispiele veranschaulicht werden.
			
			\begin{lstlisting}[style=bash]
				http://localhost:3000/objects/2
			\end{lstlisting}
			
			Angenommen der \emph{Router} empfängt eine GET-Anfrage mit obiger URL, sucht er zuerst nach dem Controller zu einer Model-Klasse namens \bashinline{object.rb},welcher nach dem \emph{Rails}-Standard \bashinline{objects_controller.rb} heisst. \\
			Die Nummer \emph{2} stellt in diesem Fall die ID des Objektes der Klasse \emph{object.rb} dar, das angezeigt werden soll. Daher leitet der \emph{Router} die Anfrage an die Methode \bashinline{show} der Klasse \bashinline{objects_controller.rb} weiter, welche sich dann um die Beschaffung der Daten zu diesem konkreten Objekt und ihre Präsentation kümmert. \\
			\\
			Der \emph{Router} muss also um Anfragen korrekt weiterleiten zu können sowohl den An"-frage-Typ als auch die URL der Anfrage interpretieren. Ohne zusätzliche Konfiguration versteht er folgende Kombinationen aus Anfrage-Typ und URL:
			
			 \begin{tabular}{l|l|l|p{6cm}}
			 	%\hline
			 		\textbf{Typ} & \textbf{Pfad} & \textbf{Methode} & \textbf{Funktion} \\ \hline %\hline
			 		GET & /objects & index & Anzeige aller Objekte der Klasse \bashinline{object.rb} \\ \hline
			 		GET & /objects/new & new & Anbieten eines Formulars um ein neues Objekt anzulegen \\ \hline
			 		POST & /objects & create & Erzeugen eines neuen Objektes \\ \hline
			 		GET & /objects/:id & show & Anzeige eines bestimmten Objektes, identifiziert über die ID \\ \hline
			 		GET & /objects/:id/edit  & edit & Anbeiten eines Formulars zum ändern eines bestimmten Objektes, identifiziert über die ID \\ \hline
			 		PUT & /objects/:id & update & Aktualisierung eines bestimmten Objektes, identifiziert über die ID \\ \hline
			 		DELETE & /photos/:id & destroy & Löschen eines bestimmten Objektes, identifiziert über die ID \\ %\hline
			 \end{tabular} 
			
			Eine Erläuterung zu den verschiedenen Anfrage-Typen folgt in Kapitel \ref{chapter:controller:request}.
			
			\subsubsection{Pfade und URLs}\label{chapter:routing:paths}
				\emph{Rails} stellt für die im vorherigen Kapitel angesprochenen \bashinline{actions} bzw. Methoden, die Anfragen vom Typ GET behandeln globale Variablen bereit mit Hilfe derer sich Anfragen ausführen lassen ohne diese ''hart'' implementieren zu müssen. Die Namensgebung dieser Variablen entspricht immer dem selben Schema.\\
				\\
				\begin{tabular}{l|l|p{7cm}}
			 		%\hline
			 		\textbf{Pfad} & \textbf{Methode} & \textbf{globale Pfad-Variable} \\ \hline %\hline
			 		/objects & index & \bashinline{objects_path} \\ \hline
			 		/objects/new & new & \bashinline{new_object_path} \\ \hline
			 		/objects/2 & show & \bashinline{object_path(2)} \\ \hline
			 		/objects/2/edit & edit & \bashinline{edit_object_path(2)} \\ %\hline
			 	\end{tabular}
				
			\subsubsection{Konfiguration des Routers}\label{chapter:routing:config}
				Um es dem \emph{Router} einer \emph{Rails}-Applikation zu ermöglichen alle Anfragen korrekt aufzulösen und weiterzuleiten, müssen die verwendeten Model-Klassen bekannt gemacht werden. Das Eintragen einer neuen Model-Klasse, sowie alle in Kapitel \ref{chapter:routing} folgenden Einstellungen lassen sich in der Konfigrationsdatei des \emph{Routers} vornehmen.
				\begin{lstlisting}[style=bash]
					<Projektverzeichnis>/config/routes.rb
				\end{lstlisting}
				Hierdurch werden Model-Klassen bekannt gemacht und die dafür vorgesehenen Standardrouten erzeugt, worauf in Kapitel \ref{chapter:routing:resources} eingegangen wird. Allerdings ist es auch möglich hier eigene Routen zu definieren, was erforderlich ist wenn man dem \emph{Router} eigens definierte Methoden eines Controllers zugänglich machen möchte. \\
				Im Rahmen der Umsetzung der \emph{Grubyware}-Plattform war dies beispielsweise für das Hoch- und Herunterladen von Dateien notwendig. Dabei wurden im betreffenden Controller die Methoden \bashinline{download} und \bashinline{upload} implementiert. Um es dem \emph{Router} zu ermöglichen Anfragen korrekt zu interpretieren und weiterzuleiten mussten in der Konfigurationsdatei die folgenden Einträge ergänzt werden.
			\begin{lstlisting}[style=paper]
			Grubyware::Application.routes.draw do
				...
				match "/dataobjects/upload" => "dataobjects#upload"
				match "/dataobjects/download/id" => "dataobjects#download#id"
      					...
			end
			\end{lstlisting}
				\textit{Anm.: dataobjects ist hierbei der Pfad auf die Klasse \path{dataobject_controller.rb} die eine Wrapper-Klasse für hochgeladene Dateien darstellt.}
				
			\subsubsection{Routing von Ressourcen}\label{chapter:routing:resources}
			Zur Bekanntmachung von Model-Klassen und Erzeugung der zugehörigen Stan"-dard-Routen bietet {Rails} ein eigenes Sprachkonstrukt an. \\
			Soll beispielsweise eine Klasse \bashinline{object.rb} im \emph{Router} registriert werden wird das in der Konfigurationsdatei \bashinline{routes.rb} wie folgt erledigt.
			\begin{lstlisting}[style=paper]
			Grubyware::Application.routes.draw do
				...
				resources :objects
				...
			end
			\end{lstlisting}
			Dadurch versteht der \emph{Router} sämtliche URLs vom Format
			\begin{lstlisting}[style=bash]
				<DOMAIN>/objects{/%}
			\end{lstlisting}
			die sich auf die in Kapitel \ref{chapter:routing:router} genannten Standardaktionen eines Controllers beziehen und stellt die in Kapitel \ref{chapter:routing:paths} angesprochenen Pfade für diese Aktionen bereit. 
			\subsubsection{Routing bei ''nested resources''}\label{chapter:routing:nested}
			\emph{Grubyware} nutzt viele Model-Klassen die in strenger hierarchischer Beziehung zueinander stehen. Dazu wurden die untergeordneten Model-Klassen im \emph{Router} als sogenannte \emph{nested resources} (eingebettete Ressource) registriert.\\ Im folgenden Beispiel wird in der Konfigurationsdatei \path{config/routes.rb} eine Model-Klasse \path{subobject.rb} als eingebettete Ressource der Model-Klasse \path{object.rb} deklariert.
			
			\begin{lstlisting}[style=paper]
			Grubyware::Application.routes.draw do
				...
				resources :objects do
					resources :subobjects
				end
				...
			end
			\end{lstlisting}
			
			Durch die explizite Deklaration von \bashinline{subobject.rb} als eingebettete Klasse der Model-Klasse \bashinline{object.rb} ergeben sich einige Änderungen für die Pfade und URLs mit denen auf konkrete Ausprägungen der Klasse \bashinline{subobject.rb} zugegriffen werden kann. \\
			Die folgende Tabelle zeigt die URLs für die Standardaktionen auf Objekten der eingebetteten Klasse und ihre entsprechenden Pfade. Dabei wird immer auf ein \emph{Kind} des konkreten Objektes der Klasse \bashinline{object.rb} mit der ID = 1 zugegriffen. \\
			\begin{table}[ht]
				\begin{tabular}{l|l|p{6.4cm}}
			 		%\hline
			 		\textbf{Pfad} & \textbf{Methode} & \textbf{globale Pfad-Variable} \\ \hline %\hline
			 		/objects/1/subobjects & index & \bashinline{object_subobjects_path(1)} \\ \hline
			 		/objects/1/subobjects/new & new & \bashinline{new_object_subobject_path(1)} \\ \hline
			 		/objects/1/subobjects/4 & show & \bashinline{object_subobject_path(1, 4)} \\ \hline
			 		/objects/1/subobject/4/edit & edit & \bashinline{edit_object_subobject_path(1, 4)} \\ %\hline
			 	\end{tabular}
				\caption{\emph{Bei Verwendung der Pfade sollte man besonders auf die korrekte Schreibweise im Bezug auf Singular und Plural achten!}}
			\end{table} 	

	Die Einbettung von Model-Klassen in andere ist über mehrere Ebenen möglich. Dabei verhält sich die Namensgebung der von \emph{Rails} erzeugten Pfade analog, also z.B.: \path{new_object_subobject_subsubobject_subsubsubobject_path(1,2,3)}. Es empfiehlt sich allerdings erfahrungsgemäß aus Gründen der Übersicht Model-Klassen nicht über mehr als drei Ebenen hinaus zu verschachteln.
			
	\section{Einf\"uhrungsbeispiel}\label{chapter:einfuehrungsbeispiel}
	Bevor detailliert auf das Arbeiten mit \emph{Rails} eingegangen wird, soll anhand einer kleinen Beispielanwendung ein erster Eindruck von der Entwicklung einer \emph{Rails}-""Applikation vermittelt werden. \\
	Dazu werden die im \emph{Ruby on Rails}-Framework integrierten Generatoren benutzt. Ziel ist es einen einfachen Blog mit Kommentarsystem zu Realisieren. Dabei wird gänzlich auf optische Aufbereitung der Oberfläche verzichtet. Es soll lediglich die grundlegende Heransgehensweise bei der Arbeit mit \emph{Ruby on Rails} vermittelt werden. \\ 
\emph{Alle Aktionen die hier illustriert sind, wurden unter Mac OS X 10.6.6 mit Hilfe der Konsole und des Editors vim ausgeführt.}
	\subsection{Projekt erzeugen}
	Zuerst muss das neue Projekt \emph{blogdemo} erzeugt werden. \\ 
	Mit Hilfe des Kommandos
	\begin{lstlisting}[style=bash]
		rails new blogdemo
	\end{lstlisting}
	legt \emph{Rails} im aktuellen Verzeichnis das Verzeichnis \emph{blogdemo} an und erzeugt darin die bereits in Kapitel \ref{chapter:structure} beschrieben Verzeichnisstruktur an.  Um mit dem angelegt Projekt arbeiten zu können betritt man mit 
	\begin{lstlisting}[style=bash]
		cd blogdemo
	\end{lstlisting}
	das Projektverzeichnis. Alle weiteren Kommandos in diesem Einführungsbeispiel können von hier aus abgegeben werden.
	
	\subsection{Erste Schritte}
	Um nun die für den Blog benötigten Klassen zu Erzeugen wird hier der Scaffold-Generator verwendet. Wie in Kapitel \ref{chapter:mvc} bereits angesprochen, baut \emph{Ruby on Rails} auf einer Form des Model-View-Controller Designmusters auf. \emph{Scaffolding} legt für das jeweils angegebene Model-Objekt alle benötigten Klassen Datenhaltung, Interaktionssteuerung und Präsentation an. 

	\subsubsection{Scaffolding}
	Der im Folgenden erzeugte Blog soll \bashinline{posts} (Beiträge) darstellen, welche einen Titel vom Datentyp \bashinline{string} und einen Inhalt vom Datentyp \bashinline{text} enthalten. \\
	Um dies zu erreichen, ruft man den \emph{Scaffold}-Generator mit den folgenden Parametern auf:
	\begin{lstlisting}[style=bash]
		rails generate scaffold post title:string content:text
	\end{lstlisting}
	
	Damit das Projekt ausführbar wird, müssen im Projektverzeichnis noch die folgenden Kommandos abgegeben werden.
	\begin{lstlisting}[style=bash]
		bundle install
		rake db:migrate
	\end{lstlisting}
	\bashinline{bundle install} ruft das Ruby-Programm \emph{Bundler} auf, welches alle im Projekt verwendeten Zusatzpakete ( genannt \emph{gems} ) für das aktuelle Projekt installiert. 
	\\ \bashinline{rake db:migrate} legt die Datenbank anhand der erzeugten Model-Klassen an. 
	
	\subsubsection{Ausf\"uhren mit WEBrick}
	Damit ist der Blog bereits lauffähig. Man kann schon jetzt Beiträge erstellen, löschen und editieren. Um das zu testen startet man den Webserver \emph{WEBrick} mit dem Kommando

	\begin{lstlisting}[style=bash]
		rails s
	\end{lstlisting}
	und ruft dann im Browser die folgende URL auf: \emph{http://localhost:3000/posts}.
	
	\begin{figure}[ht]
		\includegraphics{./img/blog_index.png}
		\caption{localhost:3000/posts mit zwei Test-Einträgen}
		\label{img:blog_index}
	\end{figure}
	
	Wie in Abbildung \ref{img:blog_index} zu sehen ist, werden erstellte Beiträge bereits in Listenform dargestellt. Auf der jeweils rechten Seite eines Betrages lassen sich die oben genannten Aktionen ausführen.

\subsection{Beziehungen realisieren}
	Um Kommentare zu einzelnen Beiträgen verfassen zu können, wird nun eine weitere Model-Klasse erstellt. Dieses soll zur Klasse \bashinline{post.rb} in einer 1:n-Beziehung stehen. Es sollen also pro Beiträg \emph{n} Kommentare erstellt werden können. \\
	Die erstellen Kommentare sollen in der jeweiligen \emph{Show}-Ansicht des Beitrags angezeigt werden zu dem Sie erstellt wurden. Dazu wird erneut der Scaffold-Generator bemüht. \\
	Anm.: Den \emph{Scaffold}-Generator an dieser Stelle zu verwenden, stellt nicht die Ideallösung dar, da viele unbenötigte Klassen und Methoden generiert werden, die in diesem Beispiel keine Verwendung finden werden. Allerdings lässt sich so schnell und einfach zeigen, wie eine lauffähige \emph{Ruby on Rails}-Applikation entwickelt werden kann.
	
	\begin{lstlisting}[style=bash]
		rails generate scaffold comment message:text
	\end{lstlisting}
	Um nun die Beziehung zwischen Beiträgen und Kommentaren zu realisieren ist etwas Handarbeit nötig. Dazu öffnet man im Editor die Model-Klasse \path{post.rb} 
	
	\begin{lstlisting}[style=bash]
		vim app/models/post.rb
	\end{lstlisting}
	
	und ergänzt diese um die benötigte Beziehung zur Klasse \path{comment.rb}, wie im Folgenden zu sehen.
	
	\begin{lstlisting}[style=paper]
		class Post < ActiveRecord:Base
			has_many :comments, :dependent => :destroy
		end
	\end{lstlisting}
	
	Im Gegenzug muss der Klasse \path{comment.rb} auch die Beziehung zu \path{post.rb} bekannt gemacht werden.
	
	\begin{lstlisting}[style=bash]
		vim app/models/comment.rb
	\end{lstlisting}
	
	\begin{lstlisting}[style=paper]
		class Comment < ActiveRecord:Base
			belongs_to :post
		end
	\end{lstlisting}
	
	\subsubsection{Eingebettete Klassen}
	Damit ist eine Beziehung zwischen den Objekten der Klassen \path{post.rb} und \path{comment.rb} hergestellt. \\
	Um die Kommentare als untergeordnete Objekte der Beiträge über die URL des Webbrowsers zugänglich zu machen muss das \emph{Routing}, welches bereits in Kapitel \ref{chapter:routing} angesprochen wurde, noch entsprechend angepasst werden. \\ 
	Dazu muss die Datei \path{routes.rb} im Editor geöffnet werden.
	\begin{lstlisting}[style=bash]
		vim config/routes.rb
	\end{lstlisting}
Der Inhalt ist wie folgt zu ändern.
	\begin{lstlisting}[style=paper]
		Blogdemo::Application.routes.draw do
			  resources :posts do
					resources :comments
			  end
			# The priority is based upon order of creation:
			...
		end
	\end{lstlisting}

Um nun der Datenbank zu ermöglichen Kommentare und Beiträge korrekt in Beziehung zu bringen, muss für Kommentare ein Feld angelegt werden, welches sich um das Auflösen der Beziehung zum jeweiligen übergeordneten Beitrag kümmert. Dies wird erreicht indem eine neue \emph{Migration} implementiert wird die die Datenbank entsprechend anpasst. Was eine \emph{Migration} ist wird im Rahmen des Kapitels \ref{chapter:migrations} erklärt. \\

Das Anlegen des benötigten Feldes übernehmen die folgenden beiden Befehle.
	
	\begin{lstlisting}[style=bash]
		rails generate migration add_post_id_to_comment post_id:integer
		rake db:migrate
	\end{lstlisting}

Durch die vollzogenen Änderungen in der Datei \path{blogdemo/config/routes.rb}, das Hinzufügen des neuen Feldes zu der Klasse \path{blogdemo/app/model/comment.rb} mittels der erzeugten \emph{Migration} und der Modellierung der Beziehung in beiden Model-Objekten sind Objekte der Klasse \path{comment.rb} jetzt in die Klasse \path{post.rb} eingebettet. Man spricht hierbei von \emph{nested resources}.

\subsection{Interaktionssteuerung}
Um nun eine Reibungslose Interaktion mit den eingebetteten Kommentaren zu gewährleisten müssen einige Eingriffe auf Steuerungs- und Präsentationsebene vollzogen werden. \\
\subsubsection{Anpassung der Beitr\"age}
Zuerst müssen die Controller der betreffenden Model-Objekte bei anstehenden \\CRUD-Operationen (Create, Read, Update, Delete) auf die Abhängigkeit zwischen Beiträgen und Kommentaren rücksicht nehmen. \\
Die Steuerung der Beiträge ( \path{post.rb} ) muss für die Anzeige eines Betrags ebenfalls die zugehörigen Kommentare der Präsentationsebene zur Verfügung stellen.

\begin{lstlisting}[style=paper, caption=blogdemo/app/controllers/posts\_controller.rb]
class PostsController < ApplicationController
	...
  	def show
		@post = Post.find(params[:id])
		@comments = @post.comments

		respond_to do |format|
			format.html # show.html.erb
		end
	end
	... 	
\end{lstlisting}

\subsubsection{Anpassung der Kommentare}
Die Steuerung der Kommentare muss bei sämtlichen Operationen auf das Pflegen der Beziehung zum jeweiligen Beitrag achten. Im Folgenden ist der gesamte \emph{Controller} gelistet.

\begin{lstlisting}[style=paper, caption=blogdemo/app/controllers/comments\_controller.rb]
class CommentsController < ApplicationController

  def show
    @comment = Comment.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
    end
  end

  def new
    @post = Post.find(params[:post_id])
    @comment = @post.comments.new

    respond_to do |format|
      format.html # new.html.erb
    end
  end

  def edit
    @post = Post.find(params[:post_id])
    @comment = Comment.find(params[:id])
  end

  def create
    @comment = Comment.new(params[:comment])
    @comment.post_id = params[:post_id] 
    respond_to do |format|
      if @comment.save
        format.html { redirect_to(post_comment_path(params[:post_id], @comment), :notice => 'Comment was successfully created.') }
      else
        format.html { render :action => "new" }
      end
    end
  end

  def update
    @comment = Comment.find(params[:id])

    respond_to do |format|
      if @comment.update_attributes(params[:comment])
        format.html { redirect_to(post_path(params[:post_id]), :notice => 'Comment was successfully updated.') }
      else
        format.html { render :action => "edit" }
      end
    end
  end

  def destroy
    @comment = Comment.find(params[:id])
    @comment.destroy

    respond_to do |format|
      format.html { redirect_to post_comments_path(params[:post_id]) }
    end
  end
end
\end{lstlisting}

\subsubsection{Anpassung der Pr\"asentationsschicht}
Auf der Präsentationsebene müssen noch Anpassungen im Bereich der verwendeten Pfadvariablen vorgenommen werden. Wie in Kapitel \ref{chapter:routing} angesprochen müssen eingebettete Klassen anders über die von \emph{Rails} bereitgestellten globalen Variablen adressiert werden als nicht eingebettete.
\\
So lässt sich die Show-Ansicht für ein Objekt einer fiktiven (nicht eingebetteten) Klasse \bashinline{comment.rb} durch die von \emph{Rails} bereitgestellte Variable \bashinline{comment\_path(id)} aufrufen.\\
Eingebettete Objekte hingegen müssen über alle übergeordneten Objekte identifiziert werden. So lässt sich die Show-Ansicht eines äquivalenten Objektes der hier verwendeten eingebetteten Klasse \bashinline{comment.rb} nur über die Variable \\ \bashinline{post\_comment\_path(post\_id, comment\_id)} erreichen. \\

Auch an dieser Stelle wird der entsprechend modifizierte Code der jeweiligen \bashinline{.html.erb}-Datein unter \emph{blogdemo/app/views/comment/}.

\begin{lstlisting}[style=paper, caption=blogdemo/app/views/comments/\_form.html.erb]
<%= form_for([@post, @comment]) do |f| %>
  <% if @comment.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@comment.errors.count, "error") %> prohibited this comment from being saved:</h2>

      <ul>
      <% @comment.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= f.label :message %><br />
    <%= f.text_area :message %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>
<% end %>
\end{lstlisting}

\begin{lstlisting}[style=paper, caption=blogdemo/app/views/comments/edit.html.erb]
<h1>Editing comment</h1>
<%= render 'form' %>
<%= link_to 'Show', post_comment_path(@post, @comment) %> |
<%= link_to 'Back', post_path(@post) %>
\end{lstlisting}

\begin{lstlisting}[style=paper, caption=blogdemo/app/views/comments/new.html.erb]
<h1>New comment</h1>
<%= render 'form' %>
<%= link_to 'Back', post_comments_path(@post) %>
\end{lstlisting}


\begin{lstlisting}[style=paper, caption=blogdemo/app/views/comments/show.html.erb]
<p id="notice"><%= notice %></p>
<p>
  <b>Message:</b>
  <%= @comment.message %>
</p>
<%= link_to 'Edit', edit_post_comment_path(params[:id], params[:post_id]) %> |
<%= link_to 'Back', post_path(params[:post_id]) %>
\end{lstlisting}

	\section{Model -- ActiveRecord}\label{chapter:activerecord}
	Rails 3 enth\"alt das Persistenz Framework \emph{Active Record}. Die grundlegene Idee eines solchen Frameworks ist es, persistente Daten in Objekten zu kapseln. Zum einen hat man so ein objektorientiertes Modell, dass sich nahtlos ins das Programm integriert, zum anderen erreicht man damit eine gewisse Unabh\"angigkeit gegen\"uber der verwendeten Datenbank.
		
	\emph{Active Record} bietet beide dieser Eigenschaften und stellt Werkzeuge bereit, die dem Entwickler die Arbeit erleichtern. Dennoch sind bis zum fertigen Model einige Schritte notwendig, die in den Folgenden Kapiteln ausf\"uhrlicher erkl\"art werden.
	
	\subsection{Migrations}\label{chapter:migrations}
	Kurz gesagt dienen \emph{Migrations} dazu, Operationen auf der Datenbank durchzuf\"uhren. Anstelle von einzelnen SQL-Statements verwendet man hier Ruby, um die Operationen auszuf\"uhren. Der Vorteil liegt darin, dass man von der zu Grunde liegenden Datenbank unabh\"angig ist. Ebenfalls folgen \emph{Migrations} einer inkrementellen Struktur, die die Versionierung besonders einfach macht.
	
	\subsubsection{Migrations im Detail}\label{chapter:activerecord:migration}
	Zun\"achst mal sind Migrations einfache Klassen, die von \emph{ActiveRecord::Migration} abgeleitet sind und die zwei Methoden \emph{up} und \emph{down} definieren:
	
\begin{lstlisting}[style=paper, caption=grubyware/db/migrate/20101214132030\_create\_users.rb, label=listing:createtable]
class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :alias
      t.string :email
      t.timestamps
    end
  end
  
  def self.down
    drop_table :users
  end
end
\end{lstlisting}
	
	In der \emph{Up}-Methode werden die gew\"unschten \"Anderungen vorgenommen, in diesem Fall wird eine Tabelle \emph{users} mit einigen Attributen erstellt. Wie man sieht, ist kein Feld f\"ur den Prim\"arschl\"ussel vorgesehen. Das liegt daran, dass beim Erstellen einer Tabelle standardm\"a{\ss}ig der Prim\"arschl\"ussel mit dem Namen \emph{id} angelegt wird, es ist also nicht notwendig ihn von Hand zu erzeugen. Ebenfalls ist das Attribut \emph{timestamps} auff\"allig. Wird es deklariert erzeugt ActiveRecord die zwei Attribute \emph{created\_at} und \emph{updated\_at}, welche automatisch beim Erzeugen bzw. \"Andern eines Active Record Objects gesetzt werden.
	
	In der \emph{Down}-Methode werden die vorherigen \"Anderungen r\"uckg\"angig gemacht (N\"aheres dazu im folgenden Abschnitt). Da in diesem Fall nur eine Tabelle erstellt wird, wird sie einfach wieder gel\"oscht. Doch man kann mit den Migrations nicht nur Tabellen anlegen, sondern auch bestehende \"andern.
	
\begin{lstlisting}[style=paper, caption=Beispiel einer Migration zum \"Andern einer bestehenden Tabelle, label=listing:migration1]
class ChangeUsers < ActiveRecord::Migration
  def self.up
    change_table :users do |t|
      t.string :receive_newsletter, :default => false
    end
    
    User.update_all ["receive_newsletter = ?", true]
  end
  
  def self.down
    remove_column :users, receive_newsletter
  end
end
\end{lstlisting}
	
	In diesem Beispiel wird der Tabelle \emph{users} das Attribut \emph{receive\_newsletter} hinzugef\"ugt, das standardm\"a{\ss}ig mit \emph{false} gesetzt wird. Anschliessend wird das Attribut in der Zeile \emph{Users.update\_all [receive\_newsletter = ?, true]} f\"ur alle bereits bestehenden Datens\"atze auf \emph{true} gesetzt. Hier ist deutlich zu erkennen, dass Migrations ganz normale Klassen sind. Es steht der gesamte Ruby-Sprachumfang zur Verf\"ugung. Im Anschluss wird noch als Invertierende Operation das Attribut wieder entfernt.
	
	Weitere Methoden sind:
	\begin{itemize}
		\item create\_table
		\item change\_table
		\item drop\_table
		\item add\_column
		\item change\_column
		\item rename\_column
		\item remove\_column
		\item add\_index
		\item remove\_index
	\end{itemize}
	
	
	Ein Nachteil an Persistenz Frameworks wie Active Rekord ist, dass ihr Funktionsumfang nicht immer vollst\"andig ausreicht. Active Record k\"ummert sich z.B. nicht um die referentielle Integrit\"at der Daten. Auch sind nicht alle Constraints im Sprachumfang enthalten, da sie in der Regel von der Datenbank abh\"angen. In diesem Fall bleibt nichts \"ubrig als SQL-Statements von Hand \"uber den \emph{execute} Befehl auszuf\"uhren.
	
	\subsubsection{Migrations erstellen}
	Der einfachste Weg eine Migration zu erstellen ist der Scaffolding Generator. Dabei gibt es grunds\"atzlich zwei M\"oglichkeiten:
	\begin{description}
		\item[Model] Ein komplettes Model erstellen:
\begin{lstlisting}[style=bash]
rails generate model User alias:string email:string
\end{lstlisting}
		Dies erzeugt eine Migration deren Inhalt genau dem aus Listing \ref{listing:createtable} entspricht. Zus\"atzlich erzeugt dieser Generator eine Model-Klasse \emph{user} im Ordner \path{./app/models} (Diese Klasse wird in den Kapiteln Associations und Validations eingehend behandelt). Der Befehl ist aufgebaut nach dem Muster: \newline
		\emph{rails generate model [Modelname] [[Attribut:Typ] [Attribut:Typ] ...]}
		\item[Migration] Nur eine einzelne Migration erstellen: 
\begin{lstlisting}[style=bash]
rails generate migration ChangeUser
\end{lstlisting}
		Dies erzeugt lediglich eine Migration mit dem angegebenen Namen sowie den leeren Methoden \emph{up} und \emph{down}. Diese Art der Migration sollte gew\"ahlt werden, wenn nur bestehende Tabellen oder Attribute ge\"andert werden m\"ussen aber kein neues Model gebraucht wird. Der Befehl ist aufgebaut nach dem Muster: \newline
	\emph{rails generate Migration [Migrationname]}
	\end{description}
	
	Jede Migration wird im Ordner \path{./db/migrate} abgelegt und folgt einem speziellen Namensschema. Der Dateiname der Migration \emph{CreateUser} sieht folgenderma{\ss}en aus: \path{YYYYMMDDHHMMSS\_create\_user.rb} \newline
	Dabei ist der erste Teil das Erstelldatum der Migration im UTC Format, gefolgt vom Klassennamen wobei vor jedem Gro{\ss}buchstaben im Klassennamen ein Unterstrich im Namen der Datei erfolgen muss. Also aus der Migration \emph{CreateUser} folgt der Dateiname \emph{[Zeitstempel]\_create\_user.rb}. \newline
	Diese Konvention ist bindend, wird der Namen einer Migration ge\"andert, muss auch der Dateiname bzw. umgekehrt ge\"andert werden. Wird dies vers\"aumt erzeugt Rails eine Fehlermeldung.
	
	\subsubsection{Migrations schreiben}
	Es gibt in Rails verschiedene Schreibweisen um das selbe auszudr\"ucken, in den nachfolgenden Beispielen werden nicht alle aufgezeigt, sondern nur die gebr\"auchlichsten. Die elementarste Operation ist das anlegen von Tabellen, wobei es f\"ur die Attribute verschiedene Datentypen und Optionen gibt.

\begin{lstlisting}[style=paper, caption=grubyware/db/migrate/20101214132159\_create\_projects]
class CreateProjects<ActiveRecord::Migration
  def self.up
    create_table :projects do |t|
      t.string :name
      t.text : description
      t.string :url
      t.string :status, :default => 'initial'
      t.integer :progress, :default => 0
      t.timestamps
    end
  end
  
  def self.down
    drop_table :projects
  end
end
\end{lstlisting}
	
	Diese Migration zeigt den prinzipiellen Aufbau einer Tabelle mit Datentypen und Optionen f\"ur die Attribute.	M\"ogliche Datentypen sind:
	
	\begin{description}
		\item[boolean] - Hat entweder den Wert \emph{true} oder \emph{false}.
		\item[date] - Datum ohne Uhrzeit.
		\item[datetime] - Datum mit Uhrzeit.
		\item[integer] - Speichert eine Ganzzahl.
		\item[float] - Speichert eine Gleitkommazahl.
		\item[string] - Text bis maximal 255 Zeichen.
		\item[text] - Text bis maximal 65536 Zeichen.
		\item[time] - Uhrzeit.
		\item[timestamp] - Datum mit Uhrzeit, das von der Datenbank bef\"ullt wird.
		\item[primary\_key] - Integer, der von der Datenbank automatisch inkrementiert wird.
		\item[binary] - Speichert bin\"are Daten.
	\end{description}
	
	M\"ogliche Optionen sind:
	
	\begin{description}
		\item[:null]  => \emph{true} oder \emph{false}. Legt fest ob ein Attribut einen Wert haben muss.
		\item[:default] => [\emph{Value}] Legt einen Standardwert f\"ur das Attribut fest.
		\item[:unique] => \emph{true} oder \emph{false}. Legt fest ob der Wert des Attributes einzigartig ist.
		\item[:limit] => Legt die Feldl\"ange f\"ur einen String oder Text fest.
	\end{description}
	
	Nat\"urlich soll das \"andern von Tabellen nicht unerw\"ahnt bleiben.

\begin{lstlisting}[style=paper, caption=Beispiel f\"ur change\_table]
def self.up
  change_table :prtojects do |t|
    t.string :example
    t.rename :name, :firstname
    t.remove :url
  end
end
\end{lstlisting}
	
	Das \"Andern von Tabellen ist dem Erzeugen recht \"ahnlich. In diesem Beispiel wird eine neue Spalte mit dem Namen \emph{example} vom Typ \emph{String} hinzugef\"ugt. Die Spalte \emph{name} wird in \emph{firstname} ge\"andert und die Spalte \emph{url} wird entfernt. Das sind die wesentlichen Operationen zum \"andern einer Tabelle.
	
	\subsubsection{Migrations ausf\"uhren}
	Nachdem nun eine oder mehrere Migrations erstellt wurden, m\"ussen diese noch auf die Datenbank angewendet werden. Dabei kommen die Zeitstempel zum tragen, denn es ist m\"oglich, dass bereits \"altere Migrations ausgef\"uhrt wurden. \newline
	Rails merkt sich immer welche zuletzt ausgef\"uhrt wurde und so kann man mit
\begin{lstlisting}[style=bash]
rake db:migrate
\end{lstlisting}
ganz einfach auf die aktuellste Version updaten. Soll nicht auf die letzte Migration aktualisiert werden, sondern auf eine vorherige, is dies m\"oglich, in dem beim Aufruf des Rake-Tasks der Zeitstempel mit \"ubergeben wird, z.B:
\begin{lstlisting}[style=bash]
rake db:migrate VERSION = 20080906120000
\end{lstlisting}
	Ist die angegebene Version gr\"o{\ss}er als die aktuelle, werden alle Migrations inklusive der angegebenen ausgef\"uhrt. Ist die Version kleiner als die aktuelle, werden alle Migrations r\"uckg\"angig gemacht exklusive der angegebenen.
	
	Jetzt wird auch deutlich wozu die \emph{Down}-Methode der Migrations notwendig ist. Migrations sind keine Einbahnstra{\ss}e sondern k\"onnen auch zur\"uckgerollt werden. Soll z.B. die letzte Migration zur\"uckgerollt werden, kann dies durch
\begin{lstlisting}[style=bash]
 rake db:rollback
\end{lstlisting}
erfolgen. Sollen mehrere r\"uckg\"angig gemacht werden, kann die Anzahl der Schritte mit angeben werden, z.B. 
\begin{lstlisting}[style=bash]
rake db:rollback STEP=4
\end{lstlisting}
	Ebenfalls k\"onnen einer oder mehrere Schritte erneut ausgef\"uhrt werden.
\begin{lstlisting}[style=bash]
rake db:migrate:redo STEP=2
\end{lstlisting}
z.B. rollt die letzten beiden Migrations zur\"uck und f\"uhrt sie erneut aus.

Beim Umgang mit Migrations sollte beachtet werden, dass es in der Regel nicht sinnvoll ist, alte Migrations zu ver\"andern. Arbeitet man alleine auf einem System ist dies weniger schlimm, aber arbeitet man auf einem gemeinsamen Repository, kann es schnell zu Chaos f\"uhren. \newline
Angenommen man muss etwas am Datenschema \"andern und anstelle einer neuen Migration, die die \"Anderung vornimmt, \"andert man eine alte und f\"uhrt sie erneut aus. Dann wird auf dem eigenen System alles in Ordnung sein, aber bei den anderen werden Probleme auftauchen, weil sie die \"Anderung nicht mitbekommen. Rails merkt sich nicht ob irgendwelche Migrations ver\"andert wurden, nur welche die aktuellste ist. Es ist daher ratsam sich gar nicht anzugew\"ohnen, bestehende Migrations nachtr\"aglich zu ver\"andern. Mal abgesehen von Syntaxfehlern, gibt es dazu auch \"uberhaupt keinen Grund.
	
	\subsection{Validations}
	Nach dem die Datenbank nun angelegt ist, k\"onnen Active Record Objekte erzeugt, ver\"andert und auch wieder zerst\"ort werden. Doch es muss sichergestellt sein, dass nur g\"ultige Daten in die Datenbank gelangen. Hier kommen die Model-Klassen ins Spiel.
	
	\subsubsection{\"Uber Validations}
	Es gibt im Lebenszyklus einer Applikation viele Stellen, an denen man die G\"ultigkeit von Daten \"uberpr\"ufen kann. Doch jede Stelle hat ihre Vor- und Nachteile und es ist gut abzuw\"agen wo man ansetzt.
	
	Das Naheliegenste ist wohl, die Konsistenz der Daten bereits in der Datenbank \"uber Constraints sicher zu stellen. Das ist aus wartungstechnischer sicht ein zus\"atzlicher Aufwand aber daf\"ur die sicherste Art die Datenkonsistenz zu sch\"utzen. Besonders wenn man bedenkt, dass durchaus mehrere Applikationen auf dem selben Datenbestand arbeiten k\"onnen, wird klar, dass das die einzig wirklich sichere Methode ist. Zus\"atzlich sind Datenbanken in der Lage \"Uberpr\"ufungen durchzuf\"uhren, die auf Applikationsebene nur schwer zu realisieren sind.
	
	Datenbank-Constraints sind also gut, aber jedes mal Daten bis in die Datenbank durchzuleiten, um dann festzustellen, dass sie ung\"ultig sind ist nicht sonderlich effizient und auch nicht sch\"on zu behandeln. Viele Eingabefehler lassen sich auch schon direkt in der Client-Applikation mit viel weniger Aufwand abfangen. Zum Beispiel Feldl\"angen oder die G\"ultigkeit von Eingabewerten \"uberpr\"ufen. Das schont die Resourcen unserers Servers sowie der Datenbank. Das Problem ist dabei allerdings, dass auf dem Weg vom Client zum Server, die Daten verf\"alscht werden k\"onnen und so wieder ung\"ultige Daten in die Datenbank gelangen k\"onnten.
	
	Clientseitige Eingabe\"uberpr\"ufung ist also nicht belastbar und daher eher als Komfortfunktion anzusehen, bleibt nur noch die serverseitige Validierung. Die Verbindungen zwischen Servern und Datenbanken sind in der Regel abgesichert und der Server selbst ist f\"ur die Applikation nicht umgehbar. Ein weiterer Vorteil der serverseitigen Validierung liegt darin, dass sie sich besonders leicht testen l\"asst, da man dazu keine aufw\"andigen Testszenarios aufbauen muss.
	
	Eine Kombination aus Datenbank-Constraints und serverseitiger Validierung ist also das Mittel der Wahl und auch Rails geht diesen Weg. Doch warum dazu extra Modelklassen und nicht einfach die Validierung in die Controller auslagern? Die Gr\"unde daf\"ur sind haupts\"achlich praktischer Natur. Zun\"achst mal braucht man so nur an einer Stelle Validierung durchzuf\"uhren, das ist \"ubersichtlich und weniger anf\"allig f\"ur Fehler. Zus\"atzlich wird so eine klare Grenze zur Applikationslogik geschaffen, was die Testbarkeit erh\"oht.
	
	\subsubsection{Zeitpunkt der Validierung}
	Validierung findet i.d.R. statt, wenn ein Active Record Object eine \"Anderung in der Datenbank ausl\"osen wird. Sprich zwischen dem Aufruf der Methode und der eigentlichen Ausf\"uhrung des entsprechenden SQL-Statements. \newline
	Methoden, die Validierung ausl\"osen sind:
	\begin{itemize}
		\item create
		\item create!
		\item save
		\item save!
		\item update
		\item update\_attributes
		\item update\_attributes!
	\end{itemize}
	Die Methoden mit ! am Ende erzeugen eine Exception, wenn der Datensatz invalide ist, die anderen nicht. \emph{save} und \emph{update\_attributes} liefern \emph{false} zur\"uck, \emph{create} und \emph{update} das Objekt.
	
	Leider ist es nicht so, dass alle Methoden, die \"Anderungen auf der Datenbank ausf\"uhren auch Validations ausl\"osen. Die folgenden Methoden geh\"oren zu diesen und sind nur mit besonderer Vorsicht zu verwenden:
	\begin{itemize}
		\item decrement!
		\item decrement\_counter
		\item increment!
		\item increment\_counter
		\item toggle!
		\item update\_all
		\item update\_attribute
		\item update\_counters
	\end{itemize}
	
	Ebenfalls das Erzeugen eines Objektes mit \emph{new} l\"ost keine Validierung aus. Das liegt daran, dass ein neu erzeugtes Objekt noch keinen Datensatz in der Datenbank repr\"asentiert, er also aus technischer Sicht unter Umst\"anden noch gar nicht valide sein kann. Das wirft die Frage auf, wie manuell herausgefunden werden kann, ob ein Objekt nun valide ist oder nicht? Ganz einfach, denn selbstverst\"andlich kann die Validierung auch explizit angesto{\ss}en werden, in dem die \emph{valid?}- bzw. die dazu komplement\"are \emph{invalid?}-Methode aufgerufen wird.
	
\begin{lstlisting}[style=paper, caption=Beispiel: \emph{valid?}]
class Project < ActiveRecord::Base
  validates :name, :presence => true
end
 
Project.new(:name => nil).valid? # false
Project.new(:name => "grubyware").valid? # true
\end{lstlisting}
	Das obige Beispiel zeigt eine simple Modelklasse \emph{Project} mit einer Vaildierung, die bewirkt, dass das Attribut \emph{:name} nicht leer sein darf. Wird nun ein Objekt erzeugt, dass keinen Namen hat, ist dies zwar vorhanden aber invalide, man kann es nicht mit \emph{save} in der Datenbank speichern. Wird dagegen ein Objekt mit Namen erzeugt, ist dies auch valide und speicherbar.
	
	Typischerweise hat ein Model mehr als ein Attribut und ein Attribut mehr als eine Validation. Um herauszufinden welche Validations fehlgeschlagen sind, gibt es die \emph{errors}-Methode, die ein Array mit s\"amtlichen Fehlernachrichten ausgibt, die w\"ahrend der Validierung aufgetreten sind.
	
\begin{lstlisting}[style=paper, caption=Beispiel: \emph{errors}]
class Project < ActiveRecord::Base
  validates :name, :presence => true, :length => { :within => 5..10 }
end
 
Project.create(:name => nil).errors
 # => {:name=>["can't be blank", "is too short (minimum is 5 characters)"]}
 
Project.create(:name => "grub").errors
# => {:name=>["is too short (minimum is 5 characters)"]}
\end{lstlisting}
	Im obigen Beispiel sind nun zwei Validations f\"ur das Attribut \emph{:name} vorhanden, es darf nicht leer sein und muss zwischen 5 und 10 Buchstaben haben. Soll ein Projekt ohne Namen angelegt werden, liefert die \emph{errors}-Methode ein Array mit beiden Fehlermeldungen. Soll ein Projekt mit zu kurzem Namen angelegt werden, enth\"alt das Array nur noch die eine Fehlermeldung. Bei mehreren Attributen w\"urde es gleich funktionieren. Will man nur die Fehlermeldungen f\"ur ein Attribut, kann man \emph{errors}[:attribut] aufrufen.
	Zu beachten ist, dass \emph{errors} den Validierungsvorgang selbst nicht anst\"o{\ss}t, sondern das Ergebnis daraus ist. Wird also z.B. ein neues Objekt erzeugt, ohne eine validierende Methode aufzurufen, gibt \emph{errors} immer ein leeres Array zur\"uck.
	
	Wie hier zu sehen ist, liefert Rails f\"ur fehlgeschlagene Validierungen tats\"achlich Textnachrichten zur\"uck, die direkt f\"ur Fehlerausgaben benutzt werden k\"onnen. Diese Fehlermeldungen sind standardm\"a{\ss}ig f\"ur die in Rails eingebauten Validations-Helfermethoden vorgegeben und k\"onnen nach eigenem Ermessen angepasst werden. Dies ist aber Teil der in Rails eingebauten Internationalisierung und wird deshalb in diesem Kapitel nicht weiter erkl\"art.
	
	\subsubsection{Validations schreiben}
	\emph{Validations} sind einfache Methoden die den Status eines Models \"uberpr\"ufen und im Fehlerfall eine Nachricht in die \emph{errors}-Collection ablegen.
\begin{lstlisting}[style=paper, caption=Beispiel: Validation-Methode]
class Project < ActiveRecord::Base
  validate :amount_is_bigger_than_one
 
  def amount_is_bigger_than_one
    errors.add(:size_violation, "is less than or equal one!") if
      amount <= 1
  end
end
\end{lstlisting}
	In diesem simplen Beispiel wird eine Funktion \emph{amount\_is\_bigger\_than\_one} angelegt, die nichts anderes macht als zu \"uberpr\"ufen ob amount gr\"o{\ss}er als 1 ist und im Fehlerfall eine Nachricht ausgibt. Aufgerufen wird sie mit \emph{validate}. \newline
	Es gibt nat\"urlich noch viel mehr M\"oglichkeiten, eigene Methoden zu schreiben und in Rails einzubetten, was aber f\"ur dieses Tutorial zu weit f\"uhren w\"urde. Im Folgenden wird ein \"Uberblick \"uber in Rails vordefinierte Helfermethoden gegeben, mit denen schon einiges an Problemen bew\"altigt werden kann.
	
	Neben der traditionellen Schreibweise f\"ur die Standardvalidierungen gibt es seit Rails 3 auch eine verk\"urzte Schreibweise. Diese ist flexibler, da man mehrere Validierungen zusammenfassen kann, aber letzten Endes bleibt es Geschmackssache, welche Schreibweise man benutzt. Im Nachfolgenden werden einige der gebr\"auchlichsten Validations in beiden Schreibweisen vorgestellt.

	Der traditionelle Weg:
\begin{lstlisting}[style=paper, caption=Beispiel: Traditionelle Validations]	
class Project < ActiveRecord::Base
  validates_presence_of :name
  validates_length_of :name, :within => 5..20, :unless => "self.name.nil?"
  validates_uniqueness_of :name, :message => "Name bereits vorhanden!"
end
\end{lstlisting}
	In diesem Beispiel wird in der ersten Validierung festgelegt, dass das Attribut \emph{:name} nicht leer sein darf. Im zweiten Schritt wird \"uberpr\"uft, ob der Name zwischen 5 und 20 Buchstaben lang ist, aber nur falls \"uberhaupt ein Name angegeben ist. Als letztes folgt eine \"Uberpr\"ufung, ob der Name bereits in der Datenbank vorhanden ist. Ist er es, wird die angegebene Nachricht ausgegeben.\newline
	Eine Validierung sieht neben der eigentlichen Methode und den zu validierenden Attributen also noch Optionen vor. Diese h\"angen zum Gro{\ss}teil von der verwendeten Validation ab und werden deshalb hier nicht aufgelistet. Nachzulesen sind sie am einfachsten via \emph{ri}.
	
	Gebr\"auchliche Validations sind:
	\begin{description}
		\item[validates\_presence\_of] Stellt sicher, dass ein Attribut einen Wert haben muss.
		\item[validates\_length\_of] Grenzt die L\"ange eines Atributes ein.
		\item[validates\_numericality\_of] \"Uberpr\"uft ob ein Attribut eine Zahl ist.
		\item[validates\_uniqueness\_of] Stellt sicher, dass der Wert eines Attributes einzigartig ist.
		\item[validates\_inclusion\_of] Definiert eine Menge von g\"ultigen Werten f\"ur ein Attribut.
		\item[validates\_exclusion\_of] Definiert eine Menge von ung\"ultigen Werten f\"ur ein Attribut.
		\item[validates\_format\_of] Definiert eine Regular Expression f\"ur den Aufbau eines Attributes.
	\end{description}
	
	Zu bedenken ist, dass s\"amtliche Valitadions serverseitig ausgef\"uhrt werden, ein \emph{validates\_uniqueness\_of} ohne entsprechendes Datenbankconstraint garantiert deshalb nicht sicher, dass keine Duplikate in der Datenbank auftreten k\"onnen. Ebenfalls sollten die Nachchrichten ausgebenden Optionen wie \emph{:message} nur verwendet werden, wenn keine Internationalisierung verwendet wird.
	
	Die verk\"urzte Schreibweise:
	
\begin{lstlisting}[style=paper, caption=Beispiel: Verk\"urzte Validations]	
class Project < ActiveRecord::Base
  validates :name, :presence => true, :length => {:within => 5..20, :unless => "self.name.nil?"}, :uniqueness => {:message => "Name bereits vorhanden!"}
end
\end{lstlisting}
	Der Vollst\"andigkeit halber noch das obige Beispiel in der verk\"urzten Schreibweise. Der wesentliche Unterschied ist, dass einem Attribut gleich mehrere Validations auf einmal zugewiesen werden k\"onnen. Die Funktion ist exakt die gleiche.
	
	\subsection{Associations}
	Wie der Name schon vermuten l\"asst, dienen Associations dazu Beziehungen zwischen Models herzustellen. Angenommen die zwei Models \emph{Person} und \emph{Adresse} stehen in Verbindung zueinander und zwar in der Art, dass eine \emph{Adresse} immer zu einer \emph{Person}, eine \emph{Person} aber mehrere \emph{Adressen} haben kann, eine \emph{1:n} Beziehung also. Dann w\"are es im objektorientierten Umfeld von Vorteil, wenn jedes \emph{Person}-Objekt 'w\"usste' welche Adressen es h\"atte, bzw. umgekehrt jedes \emph{Adresse}-Objekt 'w\"usste' zu welcher Person es geh\"ort, ohne dass man von Hand Tabellen joinen muss. Genau dies bewirken Associations. (Im Folgenden wird davon ausgegangen, dass der Leser Grundkenntnisse relationaler Datenbanken beherrscht.)
	
	\subsubsection{Beziehungstypen}
	Active Record kennt die Beziehungstypen:
	\begin{description}
		\item[belongs\_to] Unidirektionale 1:1 Beziehung
\begin{lstlisting}[style=paper]	
class Person < ActiveRecord::Base
end

class Address < ActiveRecord::Base
  belongs_to :person
end

temp = Address.create(:name => "Gotham City")
temp.person = Person.create(:name => "Bat Man")
\end{lstlisting}
		Eine Person hat eine Adresse, eine Adresse hat eine Person. Durch das \emph{belongs\_to} kann aber nur von der Adresse zur Person navigiert werden und nicht umgekehrt. Das \emph{belongs\_to} steht immer auf der Seite, auf der der Fremdschl\"ussel in der Datenbank steht.
			
		\item[has\_one] Bidirektionale 1:1 Beziehung
\begin{lstlisting}[style=paper]	
class Person < ActiveRecord::Base
  has_one :address
end

class Address < ActiveRecord::Base
  belongs_to :person
end

temp = Person.create(:name => "Bat Man")
temp.address = Address.create(:name => "Gotham City")
\end{lstlisting}
		In diesem Beispiel kann nun in beide Richtungen navigiert werden. Es muss lediglich das \emph{has\_one} auf der anderen Seite der Beziehung erg\"anzt werden.
		
		\item[has\_many] 1:n Beziehung
\begin{lstlisting}[style=paper]	
class Person < ActiveRecord::Base
  has_many :addresses
end

class Address < ActiveRecord::Base
end

temp = Person.create(:name => "Bat Man")
temp.addresses.create([{:name => "eins"}, {:name => "zwei"}])
\end{lstlisting}
		Wie im Beispiel zu sehen ist, muss nun der Plural \emph{:addresses} verwendet werden. Bei der Verwendung von \emph{addresses} muss beachtet werden, dass immer ein Array zur\"uckgeliefert wird, auch wenn nur eine Adresse vorhanden ist.
		
		\item[has\_many :through] 1:n, m:n Beziehung durch Join-Table
\begin{lstlisting}[style=paper]	
class Person < ActiveRecord::Base
  has_many :notes
  has_many :addresses, :through => :notes
end

class Notes < ActiveRecord::Base
  belongs_to :person
  belongs_to :address
end

class Address < ActiveRecord::Base
  has_many :notes
  has_many :people, :through => :notes
end

temp = Person.create(:name => "Bat Man")
temp.addresses.create(:name => "Gotham City")
Note.all # => [#<Note id:1, person_id: 1, address_id: 1>]
\end{lstlisting}
		Mit \emph{:through} k\"onnen Beziehungen \"uber Join-Tables modeliert werden. Je nach dem ob das in eine oder beide Richtungen geschieht, entspricht das einer 1:n oder m:n Beziehung. Wird \"uber Person eine Adresse angelegt, bzw umgekehrt, wird ein entsprechendes Note Objekt erzeugt.
		
		\item[has\_and\_belongs\_to\_many] Einfache m:n Beziehung
\begin{lstlisting}[style=paper]	
class Person < ActiveRecord::Base
  has_and_belongs_to_many :addresses
end

class Address < ActiveRecord::Base
  has_and_belongs_to_many :people
end
\end{lstlisting}
		Das ist eine Kurzschreibweise f\"ur eine m:n Beziehung. Anstelle die Beziehung explizit \"uber eine Join-Table zu modellieren, wird hier implizit davon ausgegangen, dass eine Join-Table mit dem Namen \emph{persons\_addresses} und den entsprechenden Fremdschl\"usselattributen existiert.
		
	\end{description}

	\subsubsection{Optionen}
	Es gibt zahlreiche Optionen beim Modelieren der Beziehungen. Im Folgenden werden nur einige n\"utzliche exemplarisch dargestellt. Die vollst\"andigen Optionen sind am einfachsten via \emph{ri} nachzulesen.
\begin{lstlisting}[style=paper, caption=./app/models/bug.rb]
class Bug < ActiveRecord::Base
  belongs_to  :project,
              :touch =>  true
  #...
  belongs_to  :author,
              :class_name => "User",
              :foreign_key => "author_id"

  belongs_to  :processor,
              :class_name => "User",
              :foreign_key => "processor_id"
  #...
end
\end{lstlisting}
	Per Konvention geht Rails davon aus, dass der Modelname aus dem Namen der Beziehung hervorgeht, sowie die Namen der Fremdschl\"ussel aus den Namen der Models gefolgt von "\_id". Also \emph{belongs\_to :user} bedeutet, dass das Model \emph{User} hei{\ss}t und der Fremdschl\"ussel \emph{user\_id}.\newline
	Es kann aber vorkommen, dass die Beziehung nicht wie das entsprechende Model hei{\ss}en soll. Im obigen Beispiel hat \emph{Bug} zwei Beziehungen zum \emph{User}, einmal als Author und einmal als Processor. In diesem Fall kann man \"uber die Optionen \emph{:class\_name} den richtigen Klassennamen, sowie \"uber die Option \emph{foreign\_key} den entsprechenden Fremdschl\"ussel angeben.\newline
	Wenn ein Bug ge\"andert wird, soll auch der Status des Projektes aktualisiert werden. Dies bewirkt die Option \emph{:touch => true}. Dadurch wird das Attribut \emph{updated\_at} des Projektes aktualisiert, wenn das des Bugs eine \"Anderung erf\"ahrt.
	
	\subsection{Query Interface}
		Active Record bietet nat\"urlich nicht nur die M\"oglichkeit Datens\"atze zu erzeugen, sondern auch sie wieder aus der Datenbank auszulesen. Damit dazu kein SQL von Hand geschrieben werden muss, kapselt das Query Interface SQL-Statements in Methodenaufrufen. Das Query Interface ist sehr komplex, daher werden im Folgenden nur einige gebr\"auchliche Statements erkl\"art und ansonsten auf die \\\cite{API Dokumentation} verwiesen.
		
	\subsubsection{find}
	Es ist nicht immer sinnvoll mit \emph{all} alle Datens\"atze aus der Datenbank zu laden. Wenn Objekte an Hand ihrer \emph{Id} aus der Datenbank gelesen werden sollen, ist die \emph{find}-Methode das ideale Mittel. Dieser Methode k\"onnen einzelne IDs und Arrays von IDs \"ubergeben werden. Je nach dem ist das Ergebnis wieder ein einzelnes Objekt oder ein Array von Objekten.
\begin{lstlisting}[style=paper, caption=Beispiel \emph{find}]
Person.find(1)
# => #<Person id: 1, name: "Hans">

Person.find([1,2])
# => [#<Person id: 1, name: "Hans">, #<Person id: 2, name: "Peter">]
\end{lstlisting}
	Zu beachten ist, dass die zu suchenden IDs auch vorhanden sein m\"ussen, ansonsten l\"ost \emph{find} eine Exception aus.
	
	\subsubsection{where}
	Die \emph{where}-Methode ist ideal wenn Ergebnisse an Hand von Attributswerten gesucht werden sollen. Es k\"onnen ein oder mehrere Parameter \"ubergeben werden sowie auch Arrays und Ranges.
\begin{lstlisting}[style=paper, caption=Beispiel \emph{where}]
Person.where(:name => "Hans")
# => [#<Person id: 1, name: "Hans", alter: 35>, #<Person id: 5, name: "Hans", alter: 47>]

Person.where(:name => "Hanse", :alter => 35)
# => [#<Person id: 1, name: "Hans", alter: 35>]

Person.where(:alter => 15..45)
# => [#<Person id: 1, name: "Hans", alter: 35>, #<Person id: 3, name: "Elsa", alter: 23>]
\end{lstlisting}
	Zu beachten ist, dass \emph{where} immer ein Array zur\"uckliefert, auch wenn nur ein oder gar kein Datensatz gefunden wurde. Sollte das erste Ergebnis zur\"uckgeliefert werden, kann der Aufruf mit \emph{first} erg\"anzt werden. Sollte das letzte Ergebnis zur\"uckgeliefert werden, kann der Aufruf mit \emph{last} erg\"anzt werden.
	
	Sollte es notwendig sein, eine Abfrage von Hand in SQL zu stellen ist dies mit \emph{where} ebenfalls m\"oglich.
\begin{lstlisting}[style=paper, caption=Beispiel SQL-Abfrage mit \emph{where}]
Person.where("name like ?", '%Hans%')
# => [#<Person id: 1, name: "Hans", alter: 35>, #<Person id: 5, name: "Hans", alter: 47>]
\end{lstlisting}
	Im obigen Beispiel wurde die \emph{sanitized} Query Methode verwendet. Dabei werden die Parameter durch ein Fragezeichen ersetzt und erst nach dem SQL-String angegeben. Zum Schutz vor SQL-Injection ist diese Schreibweise immer zu bevorzugen.
	
	\subsubsection{order}
	Alle Suchabfragen durch \emph{where} k\"onnen mit \emph{order} sortiert werden.
\begin{lstlisting}[style=paper, caption=Beispiel \emph{order}]
Person.where(:name => "Hans").order(:alter)
# => [#<Person id: 1, name: "Hans", alter: 35>, #<Person id: 5, name: "Hans", alter: 47>]

Person.where(:name => "Hans").order('alter desc')
# => [#<Person id: 1, name: "Hans", alter: 47>, #<Person id: 5, name: "Hans", alter: 35>]
\end{lstlisting}
	Es kann nach Attribut sortiert jeweils auf bzw. absteigend sortiert werden. Dabei k\"onnen einfache Attribute angegeben oder das entsprechende SQL von Hand geschrieben werden.
	
	\subsubsection{limit, offset}
	Sollen bei einer Suchanfrage nicht alle Ergebnisse, sondern z.B. nur die ersten zwei zur\"uckgeliefert werden, kann dies durch \emph{limit} erreicht werden.
\begin{lstlisting}[style=paper, caption=Beispiel \emph{limit}]
Person.limit(2)
# => [#<Person id: 1, name: "Hans">, #<Person id: 2, name: "Peter">]
\end{lstlisting}
	Soll bei der Suche der erste Datensatz \"ubersprungen werden, kann dies durch \emph{offset} erreicht werden.
\begin{lstlisting}[style=paper, caption=Beispiel \emph{offset}]
Person.limit(2).offset(1)
# => [#<Person id: 2, name: "Peter">, #<Person id: 3, name: "Hanna">]
\end{lstlisting}
	\section{Controller -- ActionController}
	\subsection{Einstieg}
	Nachdem das Routing bestimmt hat, welcher Controller verwendet wird,
	ist der Controller nun dafür verantwortlich die Anfrage, im Folgenden als Request bezeichnet, zu verarbeiten und
	eine entsprechende Ausgabe zu erzeugen.
	Zu diesem Zweck erhält der Controller das Request-Objekt, lädt oder speichert
	Daten über das Model und baut mit Hilfe einer View eine HTML-Seite.
	Da in diesem Tutorial nur ein Einstieg in Rails gegeben ist, wird auf 
	die \cite{API Dokumentation} verwiesen.
	
	\subsection{Methoden und Actions}
	Ein Controller ist eine Ruby Klasse, die von \emph{ApplicationController}
	abgeleitet ist und Methoden wie jede andere Klasse besitzt. Sobald ein
	Request bei der Applikation ankommt, entscheidet das Routing welcher
	Controller und welche Action verwendet werden. Danach erzeugt Rails eine
	Instanz dieses Controllers und ruft die Methode, die den selben Namen wie
	die Action hat, auf. Wenn also ein Benutzer  \url{/posts/new} aufruft um
	einen neuen Post anzulegen, erzeugt Rails eine Instanz des PostsControllers
	und startet die \emph{new}-Methode, falls dieses Verhalten nicht in der Datei \path{config/routes.rb}
	,wie in Kapitel \ref{chapter:routing} beschrieben, geändert wurde.
	\subsection{Parameter}
	Es ist nicht unüblich, dass man auf Daten, die vom Benutzer aus gesendet 
	wurden, oder auf sonstige Parameter vom Controller aus zugreifen möchte.
	Es gibt zwei Arten von Parametern in einer Web-Applikation: Die
	erste ist Bestandteil der URL, so genannte \emph{query string parameters}.
	Ein \emph{query string} ist alles, was in der URL hinter einem "?"\space steht.
	Die zweite Art von Parametern bezieht sich normalerweise auf \emph{POST}-Daten.
	Diese Daten kommen meist von HTML-Formularen, die ein Benutzer zuvor 
	ausgefüllt hat. Sie werden daher als \emph{POST}-Daten bezeichnet, da diese
	nur als Teil eines \emph{HTTP POST Requests} gesendet werden können. Rails
	macht allerdings keine Unterschiede zwischen diesen beiden Arten, was die
	Handhabung für Entwickler erleichtert. Beide Parameter-Typen werden in einer Hash-Map, dem sogenannten
	\emph{params-hash} gespeichert, und sind über diesen, wie in Listing \ref{listing:params} gezeigt, ansprechbar.
	\begin{lstlisting}[style=paper, caption=Verwendung des \emph{params-hash}, label=listing:params]
		class PostsController < ActiveController::Base
			def index
				if params[:owner] == "all"
					@posts = Post.all
				else
					@posts = Post.where(:id => current_user.id)
				end
			end
		end
	\end{lstlisting}
	\subsection{Session}
	Die Applikation besitzt eine Session für jeden Benutzer, in der kleine %unglückliche formulierung
	Datenmengen abgelegt und über mehrere Requests gespeichert werden können. Die Session ist nur innerhalb der 
	Controller und der View erreichbar und kann einen der folgenden Speicher-Mechanismen verwenden:
	%\newline
	\begin{description}
		\item[CookieStore] - speichert alles auf dem Client - siehe \cite{CookieStore}
		\item[DRbStore] - speichert die Daten auf einem DRb Server - siehe \cite{DRbStore}
		\item[MemCacheStore] - speichert die Daten in einem Memcache - siehe \cite{MemCacheStore}
		\item[ActiveRecordStore] - speichert die Daten in einer DB mittels ActiveRecord - siehe 
		\cite{ActiveRecordStore}
	\end{description}
	%\newline
	Jede Session hat eine eindeutige ID, welche im Cookie gespeichert wird. Diese \emph{ID} wird verwendet, um
	eine Session einem Benutzer zuzuordnen.Man muss Cookies verwenden,
	da Rails es nicht erlaubt, die Session ID in der URL mitzuschicken. Üblicherweise werden in der Session kleine
	Attribute wie Sortierreihenfolgen, das verwendete Design oder Objekt-IDs gespeichert.
	Möchte man den Session Speicher-Mechanismus ändern, so kann
	man dies in \emph{config/initializers/session\_store.rb} tun.
	
	\subsubsection{Cookies}
	Cookies bieten die Möglichkeit Informationen sessionübergreifend zu speichern, um diese z.B. beim nächsten Besuch des Benutzers wieder verwenden zu können. Rails bietet mittels der 
	\emph{cookies}-Methode einen einfachen Zugriff auf die darin gespeicherten Daten. Auch hier wieder ein einfaches
	Beispiel, welches in einem Controller stehen könnte:% \newline
	\begin{lstlisting}[style=paper]
		@post = Post.find(params[:id])
		cookies[:post_title] = @post.title
	\end{lstlisting}

	Daten können wie folgt aus dem Cookie gelöscht werden: 
	\begin{lstlisting}[style=paper]
		cookies.delete(:key)
	\end{lstlisting}
	
	\subsubsection{Zugriff auf die Session}
	Auf die Session kann mittels der \emph{Session}-Instanz-Methode zugegriffen
	werden. Session Werte sind als \emph{Key/Value}-Paare wie in einer Hash-Map
	gespeichert. Hierzu ein paar einfache Beispiele:

	\minisec{Zugriff auf Daten}
		\begin{lstlisting}[style=paper]
		class ApplicationController < ActionController::Base
			def current_user
				@_current_user ||= session[:current_user_id] 
								&& User.find(session[:current_user_id])
				# ||= ist ein ODER-GLEICH Operator, der dem Objekt auf der 
				# linken Seite etwas zuweist, wenn der Ausdruck auf der 
				# rechten Seite wahr ist, ansonsten bleibt das Objekt 
				# unverändert. Der rechte Ausdruck prüft, ob current_user_id 
				# in der Session vorhanden ist, wenn ja wird der User
				# gesucht, sonst ist der rechte Ausdruck direkt false
			end
		end
		\end{lstlisting}
		
	\minisec{Speichern in der Session}
		\begin{lstlisting}[style=paper]
		class LoginsController < ApplicationController
			def create
				if user = User.authenticate(params[:username], params[:password])
					session[:current_user_id] = user.id
					redirect_to root_url
				end
			end
		end
		\end{lstlisting}
		
	\minisec{Etwas aus der Session löschen}
		\begin{lstlisting}[style=paper]
		class LoginsController < ApplicationController
			def destroy
				@_current_user = session[:current_user_id] = nil
				redirect_to root_url
			end
		end
		\end{lstlisting}
	
	\subsubsection{Flash-Messages}
	Flash ist ein spezieller Teil der Session, welcher mit jedem Request geleert
	wird. Das bedeutet, dass diese Werte nur im darauf folgenden Request
	verfügbar sind. Dies ist nützlich, um Fehler- oder Erfolgs-Meldungen zu
	speichern. Der Zugriff erfolgt ähnlich wie der auf die Session. Ein paar
	Beispiele sollen den Umgang verdeutlichen:
	%\newline
	\begin{lstlisting}[style=paper]
		class LoginsController < ApplicationController
			def destroy
				@_current_user = nil
				flash[:notice] = "Logout erfolgreich"
				redirect_to root_url
			end
		end
	\end{lstlisting}
	%\newline
	Es ist ebenfalls möglich eine Flash-Message als Teil des Redirect zu
	vereinbaren: \newline
	\begin{lstlisting}[style=paper]
		redirect_to root_url, :notice => "Logout erfolgreich"
	\end{lstlisting}
	%\newline
	Die \emph{destroy}-Methode aus dem Beispiel von oben leitet zur
	\emph{root\_url} um, wo die Nachricht ausgegeben werden soll. Es ist üblich,
	die Flash-Messages über das App\-likations-Layout \path{application.html.erb} 
	auszugeben. Hier ein Beispiel:% \newline
	\begin{lstlisting}[style=paper]
	<html>
		<!-- <head/> -->
		<body>
			<% if flash[:notice] %>
				<p class="notice"><%= flash[:notice] %></p>
			<% end %>
			<% if flash[:error] %>
				<p class="error"><%= flash[:error] %></p>
			<% end %>
			<!-- weiteren Inhalt -->
		</body>
	</html>
	\end{lstlisting}

	Somit wird die Fehler- oder Erfolgs-Nachricht automatisch ausgegeben.
	\\
	Es gibt Situationen in denen ein \emph{Flash} nicht erst beim nächsten Request ausgegeben werden soll.
	Hierfür wird \bashinline{flash.now} verwendet. Als Faustregel kann man sich merken, dass \bashinline{flash.now}
	immer dann eingesetzt wird, wenn eine Flashnachricht vor der \bashinline{render}-Methode aufgerufen wird.	\begin{lstlisting}[style=paper, caption=Verwendung von flash.now, label=listing:flash.now]
class ProjectsController < ApplicationController
  def create
    @project = Project.new(params[:project])
    if @project.save
      # ...
    else
      flash.now[:error] = "Konnte nicht gespeichert werden"
      render :action => "new"
    end
  end
end
\end{lstlisting}	
	In Listing \ref{listing:flash.now} sieht man den Einsatz von \bashinline{flash.now}. Schlägt das erstellen eines
	Projekts fehl, so wird der String "Konnte nicht gespeichert werden" umgehend in den Flash geschrieben und das
	Formular zum erstellen neuer Projekte angezeigt.
	\subsection{Filter}
	Filter sind Methoden, welche bevor, nach oder \glqq um\grqq eine Controller Action
	ausgeführt werden. Filter werden mit vererbt, d.h. wenn sich ein Filter
	im \emph{ApplicationController} befindet, so wird dieser in jedem Controller
	der Applikation mit ausgeführt. 
	\subsubsection{Before-Filter}
	\emph{Before-Filter} können einen Request
	anhalten. Ein gebräuchlicher \emph{Before Filter} wäre z.B. ein Filter,
	der verlangt, dass ein Benutzer angemeldet ist, bevor er eine Aktion
	ausführen darf. Solch ein Filter könnte wie folgt aussehen: %\newline
	\begin{lstlisting}[style=paper]
	class ApplicationController < ActionController::Base
		before_filter :require_login
		
		private
		
		def require_login
			unless logged_in?
				flash[:error] = "Sie müssen eingeloggt sein"
				redirect_to new_login_url # Dies hält den Request an
			end
		end
		
		def logged_in?
			!!current_user
		end
	end
	\end{lstlisting}

	Da der Filter im \emph{ApplicationController} steht, erben alle anderen
	Controller diesen Filter. Das bedeutet auch, dass alle Aktionen der
	Applikation verlangen, dass der Benutzer angemeldet ist. Um dem Benutzer
	bestimmte Aktionen ohne vorherige Anmeldung zu ermöglichen, kann man einen
	\emph{skip\_before\_filter} in den gewünschten Controllern verwenden.

	\begin{lstlisting}[style=paper]
	class LoginsController < ApplicationController
		skip_before_filter :require_login, :only => [:new, :create]
	end
	\end{lstlisting}

	Die Aktionen \emph{new} und \emph{create} erfordern nun keinen Login mehr.
	Das \emph{:only} bewirkt, dass der Filter nicht für die Aktionen \emph{new}
	und \emph{create} ausgeführt wird. Darüber hinaus kann man anstatt \emph{:only}
	auch \emph{:except} verwenden. Dies bewirkt, dass der Filter nur vor den Methoden, die nicht 
	in der Klammer aufgelistet sind ausgeführt wird. Es gibt auch noch die Möglichkeit, den Filter nicht im \emph{ApplicationController}
	aufzurufen, sondern nur in bestimmten Controllern. Dazu wird die Filter-Methode
	wie gehabt im \emph{ApplicationController} definiert, jedoch erfolgt der
	Filter-Aufruf, nur noch in den Controllern, in denen dieser gewünscht ist.
	Die Verwendung von \emph{:only} und \emph{:except} gilt weiterhin.
	
	\subsubsection{After-Filter}
	Im Gegensatz zum \emph{Before-Filter} wird der \emph{After-Filter} im 
	Anschluss an die Aktion ausgeführt. Da die Aktion allerdings schon durchgelaufen
	ist, kann der Filter diese Aktion logischerweise nicht stoppen. Einen
	\emph{After-Filter} kann man nutzen, wenn man zum Beispiel etwas mitloggen möchte
	( Erfolg oder Misserfolg einer Transaktion kann dabei in eine Tabelle geschrieben werden ).
	Des weiteren hat der \emph{After-Filter} Zugriff auf die Response-Daten, 
	die zum Client gesendet werden sollen, da zum Zeitpunkt des Aufrufs eines 
	\emph{After-Filters} das Response-Objekt bereits zur Verfügung steht. Dieser
	kann dann Daten des Response-Objektes manipulieren, wie es in Kapitel 
	\ref{chapter:controller:response} beschrieben ist.
	
	\subsubsection{Around-Filter}
	\emph{Around-Filter} sind verantwortlich für das Ablaufen von Aktionen.
	Sie können demnach ein Aktion auch anhalten.%\newline
	\begin{lstlisting}[style=paper]
	class ApplicationController < ActionController::Base
		around_filter :catch_exceptions
 
		private
 
		def catch_exceptions
			yield				# yield ruft die Methode auf, die
								# eigentlich ausgeführt werden sollte
		rescue => exception		# rescue fängt die Exception ab
								# entspricht dem catch aus Java
			logger.debug "Caught exception! #{exception}"
			raise				# raise wirft dann die Exception weiter,
								# die angegeben ist. Da hier nichts
								# angegeben ist, wird auch nichts
								# weitergegeben.
		end
	end
	\end{lstlisting}
	
	\subsection{Verifizierung}
	Verifizierungen stellen sicher, dass gewisse Kriterien eingehalten werden,
	damit ein Controller oder eine Aktion abläuft. Diese können spezifizieren,
	dass ein bestimmter Schlüssel (oder mehrere in form eines Arrays) in den
	\emph{params}, \emph{session} oder \emph{flash} - Hashes vorhanden ist.
	Die Standard-Aktion, die ausgeführt wird, wenn diese Kriterien nicht eingehalten
	werden, ist das Aufrufen einer \emph{400 Bad Request}-Aktion. Man kann 
	allerdings auch eine andere Aktion aufrufen lassen und dieser Aktion dann
	\emph{Flash}-Nachrichten hinzufügen. Hier ein kleines Beispiel dazu:
	\begin{lstlisting}[style=paper]
	class LoginsController < ApplicationController
		verify :params => [:username, :password],
			:render => {:action => "new"},
			:add_flash => {
				:error => "Username and password required to log in"
			}
 
		def create
			@user = User.authenticate(params[:username], params[:password])
			if @user
				flash[:notice] = "You're logged in"
				redirect_to root_url
			else
				render :action => "new"
			end
		end
	end
	\end{lstlisting}

	Im Beispiel wird solange auf die ''new''-Aktion gerendert, bis der Benutzer
	einen gültigen Benutzernamen und Passwort eingegeben hat. Bei einer ungültigen
	Eingabe bekommt der Benutzer die Fehlermeldung ''Username and password required to log in''
	angezeigt. Sind die Eingaben gültig, so wird versucht, den Benutzer zu authentifizieren.
	Bei Erfolg ist der Benutzer eingeloggt, sieht die Erfolgsmeldung und 
	wird auf die Index-Seite weitergeleitet.
	
	\subsection{Das Request- und Response-Objekt}
	In jedem Controller hat man die Möglichkeit, auf das Request- und auf
	das Re"-sponse-Objekt zuzugreifen. Dazu wird direkt das jeweilige Objekt
	angesprochen, wie in den folgenden beiden Abschnitten näher erläutert
	wird.
	
	\subsubsection{Das Request-Objekt}\label{chapter:controller:request}
	Das Request-Objekt beinhaltet sehr viele nützliche Informationen über
	das Request, das vom Client kommt. Aus der Vielzahl von Informationen
	die man erhalten kann, wird hier nur ein Ausschnitt gezeigt.\newline
	\begin{tabular}{  p{3cm} | p{10.5cm}  }
	%\hline
		\textbf{Eigenschaft} & \textbf{Gebrauch} \\
	\hline %\hline
		host & Der für das Request verwendete Hostname \\
		\hline
		method & Die für das Request verwendete HTTP-Methode \\
		\hline
		get?, post?, put?, delete?, head? & Liefert \emph{true} zurück, 
			wenn die HTTP-Methode GET/POST/PUT/DELETE/HEAD ist \\
		\hline
		port & Die für das Request verwendete Port-Nummer (Integer) \\
		\hline
		protocol & Liefert einen String zurück, der das Protokoll beinhaltet
			z.B. \emph{"http://"}\\
		\hline
		url & Die für das Request verwendete komplette URL \\
	%\hline
	\end{tabular}
	
	Hierzu ein Beispiel:
	\begin{lstlisting}[style=paper]
	class ExampleController < ActionController:Base
		...	
		host = request.host
		...
	end
	\end{lstlisting}
	
	\subsubsection{Das Response-Objekt}\label{chapter:controller:response}
	Das Response-Objekt wird meist nicht direkt verwendet, wird aber im Laufe
	einer Aktion aufgebaut. Manchmal kann es aber auch - wie bei einem 
	\emph{After-Filter} - nützlich sein, direkten Zugriff auf das Objekt zu
	haben. Einige der Zugriffsmethoden haben zusätzlich Setter-Methoden, 
	welche einem erlauben, deren Werte zu ändern. Hier einige Beispiele.
	\newline
	\begin{tabular}{  p{3cm} | p{10.5cm}  }
	%\hline
		\textbf{Eigenschaft} & \textbf{Gebrauch} \\
	\hline %\hline
		body & Dies ist der String an Daten, der an den Client zurück
			gesendet wird. Meist HTML.\\
		\hline
		status & Der HTTP-Status Code für das Response-Objekt, wie zum 
			Beispiel 200 für ein erfolgreiches Request oder 404 für Datei
			nicht gefunden \\
		\hline
		location & Die URL auf die der Client weitergeleitet wird \\
		\hline
		charset & Der für die Response verwendete Zeichensatz. "utf-8" ist
			Standard\\
	%\hline
	\end{tabular}
	
	Hierzu ein Beispiel:
	\begin{lstlisting}[style=paper]
	class ExampleController < ActionController:Base
		...	
		render :action => "index", :status => 200
		...
	end
	\end{lstlisting}
	
	\subsection{HTTP Authentifizierung}
	Rails besitzt zwei eingebaute HTTP-Authentifikations-Mechanismen:
	\begin{itemize}
		\item Basic Authentifizierung
		\item Digest Authentifizierung
	\end{itemize}
	
	\subsubsection{HTTP Basic Authentifizierung}
	HTTP Basic Authentifizierung ist ein Authentifizierungs-Mechanismus der
	von den meisten Browsern und anderen HTTP Clients unterstützt wird. Hier
	ein Beispiel: Ein Administrationsbereich wird nur sichtbar, wenn Benutzername
	und Passwort im HTTP Basic Dialog Fenster des Browsers eingegeben werden.
	Die Benutzung ist recht einfach und benötigt nur eine einzige Methode:
	\begin{itemize}
		\item \emph{authenticate\_or\_request\_with\_http\_basic}
	\end{itemize}
	
	\begin{lstlisting}[style=paper]
	class AdminController < ApplicationController
		before_filter :authenticate
 
		def authenticate
			authenticate_or_request_with_http_basic do |username, password|
				username == "Heinz" && password == "0815Pw"
			end
		end
	end
	\end{lstlisting}
	
	Damit kann man namensraumspezifische Controller schreiben, die von 
	\glqq AdminController\grqq\space erben. Der Before-Filter wird daher für alle Aktionen
	in diesen Controllern ausgeführt und schützt diese mit der HTTP Basic 
	Authentifizierung.
	
	\subsubsection{HTTP Digest Authentifizierung}
	Die HTTP Digest Authentifizierung ist sicherer als die Basic Authentifizierung,
	da es nicht erforderlich ist, dass der Client ein unverschlüsseltes 
	Passwort versendet (HTTP Basic Authentifizierung ist über HTTPS sicher).
	Die Benutzung ist recht einfach und benötigt ebenfalls nur eine einzige Methode:
	\begin{itemize}
		\item \emph{authenticate\_or\_request\_with\_http\_digest}
	\end{itemize}
	\begin{lstlisting}[style=paper]
	class AdminController < ApplicationController
		USERS = { "Heinz" => "0815Pw" }
 
		before_filter :authenticate
 
		def authenticate
			authenticate_or_request_with_http_digest do |username|
				USERS[username]
			end
		end
	end
	\end{lstlisting}
	
	\subsection{Up- und Download von Dateien}
	Im Rahmen einer \emph{Rails}-Applikation lässt sich sehr einfach das Hoch- und Herunterladen von Dateien realisieren. Ausserdem existieren zahlreiche \emph{Gems} die eine komfortable Möglichkeit darstellen einen einfachen Datei-Upload in die eigene Applikation zu integrieren. \\
	In diesem Kapitel soll kurz darauf eingegangen werden, wie eine einfach \emph{Upload}-Funktion ohne die Zuhilfenahme von Zusatzsoftware zu implementieren ist. Dazu werden passend zu den Erläuterungen Code-Beispiele aus dem \emph{Grubyware}-Quell\-text verwendet. Das Beispiel bezieht sich dabei nur auf die Möglichkeit die hochgeladenen Dateien auf dem Dateisystem des Servers abzulegen. Weitere Optionen werden nicht betrachtet.
	
	\subsubsection{Das Upload-Formular}
	Damit ein funktionierender Upload umgesetzt werden kann, muss das Formular dass die Datei vom Benutzer entgegen nimmt als \emph{Multipart}-Formular deklariert werden. Dadurch ist es möglich neben den gewohnten HTML-Requests auch Dateien die dem \emph{MIME}-Standard folgen korrekt zu verarbeiten. \\
	\\
	\begin{lstlisting}[style=paper]
		<%= form_tag({:action => :upload}, :multipart => true) do %>
			...
		<% end %>
	\end{lstlisting}
	Zusätzlich wird hier neben der \emph{Multipart}-Deklaration mit \bashinline{:action => :upload} explizit angegeben welche Aktion des zuständigen Controller
	
	Um ein Control zu erhalten, welches dem Client die Auswahl einer lokalen Datei für den Upload ermöglicht, stellt \emph{Rails} das Kommand \bashinline{file_field} zur Verfügung. \bashinline{file_field} wird in diesem Beispiel mit zwei Parametern genutzt. 'upload' ist dabei der Name des Parameters welches an die Interaktionssteuerung übergeben wird, wobei dieser Parameter als Hash realisiert ist, welches sämtliche zusätzlich übergebenen Attribute enthällt. 'datafile' ist der Name der Datei die als Attribut in den Hash gelegt und mit übergeben wird. \\
	\\
	\begin{lstlisting}[style=paper]
		...
		<%= file_field 'upload', 'datafile' %>
		...
	\end{lstlisting}
	
	\subsubsection{Verarbeitung in der Interaktionssteuerung}
	Auf den übergebenen Hash des Formulars kann im jeweiligen Controller über das \bashinline{params}-Hash zugegriffen werden. Das darin enthaltene Attribut stellt die Datei dar, die dem Formular übergeben wurde.\\
	\\
	\begin{lstlisting}[style=paper]
		...
		@upload = params['upload']
		@file = @upload['datafile']
		...
	\end{lstlisting}
	
	Das nun im Controller verfügbare Objekt \bashinline{@file} ist eine Instanz der Klasse \\\bashinline{ActionController::UploadedFile}, deren Operationen die weitere Verarbeitung der Datei erleichtern. \\
	Über \bashinline{@file.original_filename} lässt sich der tatsächliche Name der Datei ermitteln um diesen in einem geeigneten Hüllobjekt mit dem Pfad, unter dem die Datei abgelegt werden soll zu speichern.\\
	\\
	Das folgende Codefragment ermittelt den Dateinamen speichert den Pfad und den Namen der Datei in einem solchen Objekt der in \emph{Grubyware} verwendeten Klasse \path{dataobject.rb} und speichert die Datei auf dem lokalen Dateisystem, sowie das Hüllobjekt in der Datenbank. Dabei wird der Einfachheit halber auf dieBehandlung etwaiger Fehler verzichtet.
	\\
	\begin{lstlisting}[style=paper]
		def upload
			@upload = params['upload']
			@file = @upload['datafile']
			@name = @file.original_filename
			@path = File.join( "directory", @name )
			
			@dataobject = Dataobject.new(params[:dataobject])
			@dataobject.name = @name
			@dataobject.path = @path
			
			File.open(@path, "wb") { |f| f.write( @file.read ) }
			@dataobject.save
		end
	\end{lstlisting}
	
	Dieses Beispiel ist \emph{nicht} vollständig, enthält aber bereits die gewünschten Funktionen die Datei auf dem Dateisystem abzulegen und ihr Hüllobjekt in der Datenbank zu persistieren. durch den Aufruf in Zeile 11 im obigen Code-Fragment wird die Datei geöffnet und ihr Inhalt an den durch @path beschriebenen Zielort geschrieben. \\
	Um einen reibungslosen Produktivbetrieb zu garantieren müssten die Operationen auf dem Dateisystem und der Datenbank explizit in einer Transaktion realisiert werden. Des weiteren muss ebenfalls zu jedem Zeitpunkt sichergestellt werden, dass die Struktur des Dateisystems nicht zur Fehlerursache wird, zum Beispiel durch nicht angelegte Verzeichnisse oder Dateien die durch gleichnamige Dateien überschrieben werden könnten. \\ 
	\\
	In einigen Anwendungsfällen kann es Sinn machen, den Datei-Upload im Bezug auf die Art der Dateien die hochgeladen werden dürfen, einzuschränken. Die Klasse \bashinline{ActionController::UploadedFile} bietet dafür neben der bereits verwendeten Methode \bashinline{original_filename} auch die Attribute \bashinline{content_type} oder \bashinline{size} an. \\
	Durch \bashinline{content_type} lässt sich der MIME-Typ der hochgeladenen Datei bestimmen und so programmatisch Einschränken. \bashinline{size} gibt die Größe der gegebenen Datei in Bytes an. \\
	\\
	Ein Beispiel für die Verwendung aller erklärten Techniken ist die Methode \bashinline{upload} der Klasse \bashinline{dataobjects_controller} im \emph{Grubyware}-Projekt.
	
	\subsubsection{Download}
	Das Herunterladen der vorher gespeicherten Dateien umzusetzen ist deutlich weniger Aufwand. Dazu muss lediglich im Controller der Hüllklasse einer Datei eine entsprechende Methode bereitgestellt werden, die die konkrete Instanz und damit den Pfad der Datei auf dem Dateisystem aus der Datenbank liest. \\
	Die Übertragung zum Client wird durch das Kommando \bashinline{send_file} initiiert. Das folgende Code-Fragment zeigt die betreffende Zeile aus dem \emph{Grubyware}-Projekt.
	\\
	\begin{lstlisting}[style=paper]
		def download
			...
			send_file(@dataobject.path, :filename => @dataobject.name)
			...
		end
	\end{lstlisting}
	
	Der Parameter \bashinline{:filename} gibt hierbei den Dateinamen an, der dem Client als Standardwert zur Speicherung angeboten wird. \\
	\\
	Um die den Datei-Download in der Präsentation auslösbar zu machen, wird lediglich ein Link auf die vorher definierte Methode, die das Kommando \bashinline{send_file} enthällt, implementiert.
	\\
	\begin{lstlisting}[style=paper]
		def download
			...
			<%= link_to 'Download' , :controller => 'dataobjects', :action => 'download', :id => dataobject.id %>
			...
		end
	\end{lstlisting}
	
	Dadurch wird mit geringem Aufwand eine einfache Variante mit Dateitransfers zwischen Client und Webserver umzugehen realisiert. Dateien werden nach dem Transfer auf dem Dateisystem abgelegt und können dort wieder eindeutig gefunden werden. Desweiteren können je nach Anwendungsfall Einschränkung für Datei-Uploads bezüglich Typ und Größe gestellt werden. Auf das Löschen von gespeicherten Dateien wurde an dieser Stelle verzichtet.
	
	\subsection{Parameter-Filterung}
	Rails legt für jede Umgebung eine Log-Datei im \path{log} Ordner an. 
	Möchte man verhindern, dass vertrauliche und geheime Daten in die Log-Datei geschrieben werden, so verwendet
	man die \emph{filter\_parameter\_logging}-Methode. Dies funktioniert durch Ersetzen von bestimmten Werten in der
	\emph{params-Hash} mit dem Eintrag "[FILTERED]". Hier ein Beispiel, wie alle Parameter mit
	\glqq password\grqq\space im Schlüssel gefiltert werden können.
	\begin{lstlisting}[style=paper]
	class ApplicationController < ActionController::Base
		filter_parameter_logging :password
	end
	\end{lstlisting}
	
	\section{View -- ActionView}\label{chapter:view}
	Die ActionView ist für die Pr\"asentation verantwortlich. Sie generiert dynamisch die im
	Browser angezeigten HTML-Seiten und stellt Formulare zum erstellen von Datensätzen
	bereit. Dabei wird in den HTML-Dateien integrierter Ruby-Code ausgeführt. Im Folgenden wird davon ausgegangen, dass
	\emph{resourcful Routes} verwendet werden.
%	jeden Controller eine eigene View-Struktur, in der jeder View eine eigene 
%	Action zugeordnet ist. Des weiteren besitzt jeder Controller, der eine \emph{new}
%	und/oder \emph{edit}-Methode besitzt, auch eine Form-View (\emph{\_form.html.erb}).
%	Das Konzept der View ist ähnlich aufgebaut, wie das des Controllers. Während
%	im jeder Controller von ActionController abgeleitet ist, ist jede View, wenn
%	diese aufgerufen wird, Bestandteil der \emph{application.html.erb} aus dem Ordner
%	\emph{layouts}.
	\subsection{Aufbau einer View}
	Eine View wird ähnlich aufgebaut wie eine HTML-Seite, mit dem Unterschied, dass
	lediglich der <body>-Teil geschrieben werden muss. Der Rest, sprich <head>,
	sonstige Metainformationen und der Doctype, befindet sich in der \path{application.html.erb}.
	Diese \path{application.html.erb} sieht aus, wie in Listing \ref{listing:app.html.erb}. Über \lstinline{<%= yield %>} wird dann die jeweilige View eingebunden.
	Views beinhalten prinzipiell zwei grundlegende Elemente:
	\begin{itemize}
		\item Darstellung von Daten
		\item Navigation und Links
	\end{itemize}
	\begin{lstlisting}[style=paper,caption=eine einfache application.html.erb,label=listing:app.html.erb]
<!DOCTYPE html>
<html>
<head>
  <title>Blogdemo</title>
  <%= stylesheet_link_tag :all %>
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>
</head>
<body>

<%= yield %>

</body>
</html>
	\end{lstlisting}
	Sowohl die Darstellung von Daten, als auch die Navigation, wird mit Hilfe von 
	railsspezifischen \emph{Tags} dargestellt. Man kann jedoch die Daten, wie in 
	HTML gewohnt, formatieren. Das bedeutet, dass alle zulässigen HTML-Tags auch 
	hier zulässig sind. Ruby-Code der beim Aufruf der Seite ausgeführt werden soll, muss in ein \lstinline{<% %>}-Tag  geschrieben werden. Soll der Code eine Ausgabe erzeugen so ist ein \lstinline{<%= %>}-Tag zu verwenden. In den folgenden beiden Abschnitten wird anhand eines
	Beispieles verdeutlicht, wie eine einfache View aufgebaut ist.
	\subsubsection{Darstellung von Daten}
	Um Daten in der View darstellen zu können, müssen diese erst einmal vom Controller
	beschafft werden. Dazu betrachten wir zunächst folgenden Code, der an das 
	Einführungsbespiel aus Kapitel \ref{chapter:einfuehrungsbeispiel} angelehnt 
	ist:
	\begin{lstlisting}[style=paper]
	class PostsController < ApplicationController
		...
		def index
			@posts = Posts.all

			respond_to do |format|
				format.html # show.html.erb
			end
		end
		...
	end
	\end{lstlisting}

	Zeile 4 liefert also die Daten und speichert sie in \emph{@posts} zwischen.
	Somit kann man über \emph{@posts} auf die Daten zugreifen und diese ausgeben.
	Betrachten wir nun die Darstellung der Daten in der \path{index.html.erb}.
	Angenommen, man möchte die Beiträge (\emph{posts}) in einer Tabelle
	ausgeben.
	\begin{lstlisting}[style=paper]
	<h1>Listing all posts<h1>
	<table>
		<tr>
			<th>Title</th>
			<th>Content</th>
		</tr>
		<% @posts.each do |post| %>
			<tr>
				<td><%= post.title %></td>
				<td><%= post.content %></td>
			</tr>
		<% end %>
	</table>
	\end{lstlisting}

	Nun hat man eine fertige View, die alle Beiträge ausgibt.
	Das obige Beispiel verwendet eine Schleife zur Ausgabe.
		
	\subsubsection{Navigation und Links}
	Sind alle Beiträge ausgegeben, ist es vielleicht auch ganz nützlich,
	dass man auch die Kommentare dazu betrachten kann. Dazu wird ein Link hinter
	den jeweiligen Beitrag gesetzt, der die entsprechende Aktion aus dem 
	Controller aufruft. Ein Link wird grundsätzlich nach Folgendem Schema erzeugt: 
	\lstinline{link_to text, url, optionen}. Für weitere Optionen wird auf \bashinline{ri}
	verwiesen. Die hier verwendeten Helper-Me"-tho"-den werden von Rails, wie in
	Kapitel \ref{chapter:routing} beschrieben, generiert.
	\begin{lstlisting}[style=paper]
		...
		<td><%= post.title %></td>
		<td><%= post.content %></td>
		<td><%= link_to 'Detail', post %></td>
		...
	\end{lstlisting}
	Dieser Link ruft automatisch die Aktion \emph{show} aus dem PostsController 
	auf. In dieser Aktion können alle zu dem Beitrag gehörenden
	Kommentare aus der Datenbank geladen und entsprechend dem Beispiel ausgeben werden.
	Die folgenden Codebeispiele zeigen die Links für das Anlegen, Editieren und
	das Löschen eines Beitrags:
	\minisec{Anlegen}
		\begin{lstlisting}[style=paper]
			<%= link_to 'New Post', new_post_path %>
		\end{lstlisting}
	\minisec{Editieren}
		\begin{lstlisting}[style=paper]
			<%= link_to 'Edit Post', edit_post_path(post) %>
		\end{lstlisting}
	\minisec{Löschen}
		\begin{lstlisting}[style=paper]
			<%= link_to 'Delete Post', post, :confirm => 'Are you sure?',
				 :method => :delete %>
		\end{lstlisting}
	Als nächstes betrachten wir die Datei \path{show.html.erb} in der wir auch die
	Kommentare zu den Beiträgen ausgeben.
	\begin{lstlisting}[style=paper]
	<p>
		<b>Title:</b>
		<%= @post.title %>
	</P>
	<p>
		<b>Content:</b>
		<%= @post.content %>
	</p>
	<% @post.comments.each do |comment| %>
		<%= comment.message %>
		<br />
	<% end %>
	\end{lstlisting}

	Um von der Datei \path{show.html.erb} wieder auf die Index-Seite zu gelangen, wird
	ein Link verwendet:
	\begin{lstlisting}[style=paper]
	<%= link_to 'Back', posts_path %>
	\end{lstlisting}

	Nun kann man auch erkennen, dass bei den Links eine Konvention vorhanden
	ist. Handelt es sich um ein einzelnes Objekt, das beispielsweiße angezeigt 
	werden soll, so ist der Objektname im Link singular, wird dagegen von mehreren
	gesprochen, wie der Zurücklink, ist der Objektname plural.

	\subsection{Die \_form.html.erb}
	Wie zu Beginn des Kapitels schon angesprochen, gibt es eine Datei
	\path{_form.html.erb}, die dafür zuständig ist, ein Formular zum Anlegen
	und Editieren von Objekten (in unserem Beispiel sind das die Beiträge und
	Kommentare) bereit zu stellen. Das folgende Beispiel zeigt den Aufbau:
	\begin{lstlisting}[style=paper]
	<%= form_for(@post) do |f| %>
		<div>
			<%= f.label :title %><br />
			<%= f.text_field :title %>
		</div>
		<div>
			<%= f.label :content %><br />
			<%= f.text_area :content %><br />
		</div>
		<div>
			<%= f.submit %>
		</div>
	<% end %>
	\end{lstlisting}
	In diesem Formular sind bereits vier Elemente vorhanden, die man so ähnlich
	aus der HTML kennt:
	\begin{description}
		\item[label] eine Beschriftung
		\item[text\_field] ein einzeiliges Eingabefeld
		\item[text\_area] ein mehrzeiliges Eingabefeld
		\item[submit] ein Button der das Formular abschickt
	\end{description}
	Es gibt eine Vielzahl an solchen Elementen. Für eine vollständige Liste
	und die genaue Verwendung siehe \cite{API FormHelper}.
	\newline
	\newline
	Das folgende Beispiel soll zeigt, wie man durch die Verwendung
	der Methode \lstinline{render}, solch ein Formular in eine HTML-Seite einbinden kann:
	\begin{lstlisting}[style=paper, caption=new.html.erb]
	<h1>New Post</h1>

	<%= render 'form' %>

	<%= link_to 'Back', posts_path %>
	\end{lstlisting}

	Wird die \path{_form.html.erb} für das Editieren verwendet, füllt
	Rails die Felder automatisch mit dem vorhandenen Inhalt aus.
	
	\subsection{Ausgabe von Daten mittels Partials}
	Damit Views nicht zu unübersichtlich werden und um Redundanz zu vermeiden,
	kann man Code auch in sogenannte Partials auslagern, der dann bei Bedarf
	an der entsprechenden Stelle aufgerufen wird. Auch hier stößt man auf eine
	Konvention von Rails: Ein Partial beginnt stets mit einem Unterstrich.
	Betrachten wir die folgenden Codebeispiele, um zu verstehen wie Partials
	aufgebaut sind und wie sie verwendet werden.
	\begin{lstlisting}[style=paper, caption=views/comments/\_comment.html.erb]
	<div>
		<%= comment.message %>
		<%= link_to 'Edit', edit_comment_path(comment) %>
		<%= link_to 'Delete', comment, :confirm => 'Are you sure?', 
			:method => :delete %>
	</div>
	\end{lstlisting}

	\begin{lstlisting}[style=paper, caption=views/posts/show.html.erb]
	<p>
		<b>Title:</b>
		<%= @post.title %>
	</P>
	<p>
		<b>Content:</b>
		<%= @post.content %>
	</p>
	<% if !@post.comments.empty?  %>
		<%= render :partial => "comments/comment", 
			:collection => @post.comments.order("created_at desc") %>
	<% end %>
	\end{lstlisting}

	Die Abfrage, ob überhaupt Kommentare für einen Beitrag vorhanden sind, sollte
	man auf jeden Fall machen, da es sonst zu einer Fehlermeldung kommt. Der
	Aufruf des Partials erfolgt immer über den Pfad, d.h. über den Ordnernamen,
	in dem das Partial liegt und der Name das Partial (ohne Unterstrich und
	ohne Dateiendung). Des weiteren übergibt man dem Partial eine Kollektion;
	und zwar die Kollektion an Objekten, die ausgegeben werden soll.
	Im obigen Beispiel werden die Kommentare noch nach dem Erstellungsdatum sortiert.

	\subsection{Stylesheets}
	Natürlich kann man in Rails auch Stylesheets einbinden. Den Aufbau eines Stylesheets,
	kann man wie gewohnt vornehmen. Die Stylesheets werden, wie in Kapitel \ref{chapter:structure} 
	erläutert, im Ordner \path{/public/stylesheets/} abgelegt. Das Einbinden erfolgt einmalig in der 
	\path{application.html.erb}:
	\begin{lstlisting}[style=paper, caption=Ausschnitt aus /grubyware/app/views/layouts/application.html.erb]
	...
	<head>
		<title>Grubyware</title>
		<%= stylesheet_link_tag 'reset.css' %>
		<%= stylesheet_link_tag 'form.css' %>
		<%= stylesheet_link_tag 'grubyware.css' %>
		<%= csrf_meta_tag %>
	</head>
	...
	\end{lstlisting}
	
	\subsection{Zusammenfassung}
	In diesem  Kapitel wurde beschrieben und anhand von Beispielen gezeigt, wie 
	eine View generell aufgebaut ist, wie man Formulare verwendet, wie man
	Redundanzen mit Partials vermeiden kann und wie Stylesheets eingebunden werden. 
	Für eine detailiertere Erklärung der ActionView und 
	deren FormHelper wird auf die \\\cite{API Dokumentation} und auf 
	\cite{FormHelper Guide} verwiesen.

	\section{Deployment}
	Diese Kapitel beschäftigt sich mit der Frage wie die entstandene Webapplikation auf einem Produktivsystem eingerichtet und verfügbar gemacht 
	werden kann. Da in der Praxis meistens Linux-Server eingesetzt werden wird die Vorgehensweise exemplarisch an einem \emph{Debian 5.0}
	System erläutert. Als Applikationsserver wird sowohl auf den \emph{Apache httpd} mit einem Ruby-Modul, als auch auf den \emph{Apache Tomcat}
	eingegangen.
	
	\subsection{Ruby-Umgebung}
	Der erste Schritt besteht darin eine Ruby-Umgebung einzurichten. Hierzu kann entweder die Paketverwaltung des Systems verwendet werden, 
	oder der \emph{Ruby Version Manager} kurz \emph{RVM} eingesetzt werden. Wie eine Ruby-Installation durch die Paketverwaltung vorgenommen
	wird, kann der Dokumentation der entsprechenden Distribution entnommen werden. 
	
	Eine Ruby-Installation mit \emph{RVM} ist zwar aufwändiger als durch die Paketverwaltung, bietet jedoch den Vorteil einer aktuelleren 
	Ruby-Version als sie den meisten Distributionen beiligt. Um \emph{RVM} installieren zu können müssen zuerst einige Abhängigkeiten 
	erfüllt werden. Diese sind: \emph{git} (ein verteiltes Versionsverwaltungssystem), \emph{curl} (ein Kommandozeilenprogramm zum Zugriff auf 
	HTTP-Seiten) und ein C-Compiler (Beispielsweise \emph{gcc} welcher bei \emph{Debian} im Paket \glqq build-essential\grqq\space enthalten
	ist). Sind diese Abhängigkeiten erfüllt kann mit der \emph{RVM}-Installation begonnen werden. Hierzu gibt man in seinem Heimatverzeichnis
	ein einem Terminal \lstinline[style=bash-inline]{bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )} ein. Anschließend 
	bearbeitet man die Datei \emph{.bashrc} die sich im selben Verzeichnis befindet wie es unter \cite{RVM-Doku} im Abschnitt \emph{Post Install} 
	beschrieben wird. Ist die \emph{.bashrc}-Datei angepasst, so kann man mit \lstinline[style=bash-inline]{bash} eine neue Shell öffnen, in der man 
	\emph{RVM} mit dem Befehl \lstinline[style=bash-inline]{rvm} ausführen kann.
	
	Die Ruby-Umgebung die nun mit \emph{RVM} installiert wird hängt vom verwendeten Applikationsserver ab. 
	 \paragraph{\emph{Apache httpd}}
	 Um die Applikation auf einem \emph{Apache http} zu betreiben wird Listing \ref{rvm-apa} ausgeführt.
	\begin{lstlisting}[style=bash, caption=Ruby-Installation für \emph{Apache httpd}, label=rvm-apa]
	rvm install ruby-1.9.2
	rvm use --default ruby-1.9.2
	\end{lstlisting}
	Anschließend wird \emph{Ruby on Rails} mit der Anweisung \lstinline[style=bash-inline]{gem install rails} installiert.
	
	\paragraph{\emph{Apache Tomcat}}
	Für eine Ruby-Installation für \emph{Apache Tomcat} wird entsprechend den Anweisungen in Listing \ref{rvm-tom} durchgeführt.
	\begin{lstlisting}[style=bash, caption=Ruby-Installation für \emph{Apache Tomcat}, label=rvm-tom]
	rvm install jruby
	rvm use jruby
	\end{lstlisting}
	\emph{Ruby on Rails} wird durch die Anweisung \lstinline[style=bash-inline]{jruby -S gem install rails} bewerkstelligt.
	
	\subsection{Installation der Applikation}
	Zuerst muss der Quellcode aus dem Versionsverwaltungssystem des Projektes auf den Server transferiert werden. Am Beispiel von \emph{Grubyware}
	geschieht dies wie in Listing \ref{svn} gezeigt. Dadurch entsteht im aktuellen Verzeichnis ein Unterverzeichnis mit dem Namen \emph{Grubyware}.
	\begin{lstlisting}[style=bash, caption=Herunterladen des Quellcodes, label=svn]
	svn co https://grubyware.googlecode.com/svn/trunk/src/Grubyware Grubyware
	\end{lstlisting}
	Nun wechselt man mit \lstinline[style=bash-inline]{cd Grubyware} in das Verzeichnis der Applikation. 
	
	\paragraph{\emph{Apache httpd}}
	Da \emph{Grubyware} so konfiguriert ist, dass es im Produktivbetrieb auf einer \emph{MySQL}-Datenbank aufbaut, ist für das folgende Kommando
	\lstinline[style=bash-inline]{bundle install --deploy --without=developement test} eine Installation von \emph{libmysqlclient} notwendig, welche
	über die Paketverwaltung erfolgt.
	
	\paragraph{\emph{Apache Tomcat}}
	Da für die Installation auf dem \emph{Apache Tomcat} Server die Verwendung von \emph{JRuby} als Interpreter notwendig ist, muss ein separates \emph{Gemfile} angelegt werden. Dazu überschreibt man wie in Listing \ref{mv-gemfile} gezeigt die Dateien \emph{Gemfile} und \emph{Gemfile.lock}.
	Anschließend können mit der Anweisung \lstinline[style=bash-inline]{jruby -S bundle install --deployment --without=developement test} die von der 
	Applikation geforderten \emph{gems} installiert werden.
	\begin{lstlisting}[style=bash, caption=Überschreiben der Gemfiles, label=mv-gemfile]
	mv Gemfile.tomcat Gemfile
	mv Gemfile.tomcat.lock Gemfile.lock
	\end{lstlisting}
	
	\subsection{Datenbank anlegen}
	Wie bereits im vorherigen Abschnitt erwähnt ist \emph{Grubyware} konfiguriert in der Produktivumgebung eine \emph{MySQL}-Datenbank zu 
	verwenden, weshalb an dieser Stelle nur das einrichten einer solchen besprochen wird. Listing \ref{mysql} zeigt, wie man eine Datenbank
	anlegt, einen Nutzer erstellt und diesem Nutzer die erforderlichen Rechte für die erstellte Datenbank erteilt. Es wird vorausgesetzt, dass das
	Administratorkonto oder eines mit ausreichenden Berechtigungen zur Verfügung steht. Wörter in spitzen Klammern die komplett in Großbuchstaben
	sind, müssen durch die entsprechenden Werte ersetzt werden, wobei auch die spitzen Klammern ersetzt werden.
	\begin{lstlisting}[style=bash, caption=Anlegen der Datenbank, label=mysql]
	mysqladmin create <DATENBANKNAME> -u <DATENBANKADMINKONTO> -p
	mysql -u <DATENBANKADMINKONTO> -p
	# hier werden sie nach dem Administratorkennwort gefragt
	mysql>CREATE '<USERNAME>'@'<HOSTNAME>' IDENTIFIED BY '<PASSWORD>';
	# die Werte die fuer <USERNAME>, <PASSWORD> und <DATENBANKNAME> eintragen werden, werden im nächsten Schritt für die Konfiguration der Applikation benötigt
	mysql>GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `<DATENBANKNAME>`.* TO '<USERNAME>'@'<HOSTNAME>';
	\end{lstlisting}
	
	\paragraph{database.yml}
	Die Werte die für <DATENBANKNAME>, <USERNAME> UND <PASSWORD> verwendet wurden müssen nun in der Datei \emph{database.yml}
	im \emph{config}-Ordner der Applikation bei \glqq production\grqq\space eingetragen werden.
	\begin{lstlisting}[style=bash]
	production:
 	  adapter: <%= defined?(JRUBY_VERSION) ? 'jdbcmysql' : 'mysql2' %>
  	  database: <DATENBANKNAME>
  	  pool: 5
  	  timeout: 5000
  	  host: localhost
   	  username: <USERNAME>
  	  password: <PASSWORD>
	\end{lstlisting}
	Nun kann die Applikation auf die Datenbank zugreifen. Um die Tabellen anzulegen führt man für \emph{Apache httpd} 
	\lstinline[style=bash-inline]{rake db:migrate RAILS_ENV=production} gefolgt von 
	\lstinline[style=bash-inline]{rake db:setup RAILS_ENV=production} aus. Für \emph{Apache Tomcat} werden die selben Anweisungen mit jeweils 
	vorangestelltem \lstinline[style=bash-inline]{jruby -S} ausgeführt.
	
	\subsection{Applikationsserver konfigurieren}
	Um die Applikation nun auf dem entsprechenden Applikationsserver zu veröffentlichen sind unterschiedliche Schritte notwendig.
	\paragraph{\emph{Apache httpd}}
	Um eine \emph{Ruby on Rails} Applikation auf einem \emph{Apache httpd} Webserver veröffentlichen zu können benötigt man zunächst
	ein Apache-Modul. Dieses installiert man mit der Anweisung \lstinline[style=bash-inline]{gem install passenger}. Die Installation des Moduls
	startet man mit dem Befehl \lstinline[style=bash-inline]{sudo passenger-install-apache2-module} (falls man als \emph{root} am System angemeldet
	ist entsprechend ohne \emph{sudo}). Die Installation des Moduls ist sehr gut Dokumentiert. Nun muss das Modul konfiguriert und aktiviert werden.
	Auf Debian-Systemen befinden sich die Konfigurationsdateien für Apache-Module in \emph{/etc/apache2/mods-available}. Dort werden mit 
	\emph{root}-Rechten die Datei {passenger.conf} mit dem Inhalt in Listing \ref{passenger:conf} sowie die Datei \emph{passenger.load} mit dem Inhalt 
	aus Listing \ref{passenger:load} erstellt. Die entsprechenden Pfade werden dem Benutzer bei der Installation des Moduls mitgeteilt, <PFAD\_ZUR\_RUBY\_INSTALLTION> lässt sich alternativ auch mit \lstinline[style=bash-inline]{which ruby} ermitteln. Unter Debian wird das Modul mit dem Befehl \lstinline[style=bash-inline]{a2enmod passenger} aktivieren.
	\begin{lstlisting}[style=bash, caption=passenger.conf, label=passenger:conf]
	PassengerRoot <PFAD_ZUR_PASSENGER_INSTALLATION>
	PassengerRuby <PFAD_ZUR_RUBY_INSTALLATION>
	\end{lstlisting}
	\begin{lstlisting}[style=bash, caption=passenger.load, label=passenger:load]
	LoadModule passenger_module <PFAD_ZUM_PASSENGER_MODUL>
	\end{lstlisting}
	Damit ist der \emph{Apache httpd} in der Lage Rails-Applikationen anzubieten. Um nun beispielsweise \emph{Grubyware} zu veröffentlichen,
	muss in \emph{/etc/apache2/sites-available} eine Datei angelegt werden. Der Name der Datei kann frei gewählt werden, es empfiehlt sich jedoch
	den Namen der Applikation bzw. der verwendeten Domäne zu verwenden. Der Inhalt der Datei sollte wie in Listing \ref{virt-host} gezeigt aussehen 
	wobei <SERVERNAME> in diesem Beispiel etwa \emph{www.grubyware.de} lauten könnte. <GRUBYWARE\_PFAD> ist durch den absoluten Pfad
	zum \emph{public}-Ordner der Webapplikation zu ersetzen, in unserem Beispiel \emph{/home/user/Grubyware/public}.
	\begin{lstlisting}[style=bash, caption=grubyware.site, label=virt-host]
	<VirtualHost *:80>
			ServerName <SERVERNAME>
			DocumentRoot <GRUBYWARE_PFAD>
	</VirtualHost>
	\end{lstlisting}
	\paragraph[]{\emph{Apache Tomcat}}
	Um eine \emph{Ruby on Rails} Applikation auf einem \emph{Apache Tomcat} veröffentlichen zu können, muss zunächste mit 
	\lstinline[style=bash-inline]{jruby -S gem install warbler} ein Programm installiert werden, dass die Applikation in eine \emph{.war}-Datei
	packt. Anschließend wird im Grubyware-Verzeichnis der befehl \lstinline[style=bash-inline]{warble} ausgeführt. Dies führt dazu, dass im aktuellen 
	Verzeichnis eine Datei mit dem Namen \emph{Grubyware.war} entsteht. Diese Datei kopiert man nun in das \emph{webapps}-Verzeichnis des
	\emph{Tomcat}-Servers, im Fall von Debian 5 \emph{/usr/local/tomcat/webapps}.

	\subsection{Fehlerbehebung}
	Um die Fehlersuche und Behebung möglichst kurz zu halten folgt eine Auflistung häufiger Fehler und passende Lösungsstrategien.
	\minisec{\emph{Apache Tomcat}}
	Die Fehlerwirkung der hier beschriebenen Fehler ist stets die Selbe: Die Fehlerseite für einen Serverfehler mit dem Fehlercode 500 wird angezeigt.
	Wird hingegen ein Stacktrace oder ähnliches dargestellt, so handelt es sich um Fehler in der Applikation und nicht um Fehler die beim 
	Veröffentlichen entstanden. Bei einem Fehler sollte zuerst eine Analyse der Log-Dateien erfolgen. Diese befinden sich im Verzeichnis des 
	\emph{Tomcat}-Servers im Unterverzeichnis \emph{logs}. Die Log-Dateien von Interesse sind dabei \emph{localhost.JJJJ-MM-TT.log} (entsprechend dem aktuellen Datum) und \emph{catalina.out}. Es empfiehlt sich zuerst die \emph{localhost.log} Datei
	und danach \emph{catalina.out} zu begutachten. In Tabelle \ref{tab:fehlerbehandlung} werden die Fehlermeldungen aufgezählt, und mögliche Lösungen erläutert.\\
	\begin{table}
	\caption{Fehlerbehandlung für \emph{Apache Tomcat}}
	\label{tab:fehlerbehandlung}
	\begin{tabular}{p{0.3\textwidth}|p{0.3\textwidth}|p{0.3\textwidth}}
		\textbf{Fehlerbezeichnung} & \textbf{Log-Eintrag} & \textbf{Lösung} \\ \hline
		Datenbankzugriff & RuntimeError (The driver encountered an unknown error:\newline java.sql.SQLException: Access denied for user & Zugangsdaten für die Datenbank in \path{tomcat/webapps/Grubyware/WEB-INF/config/database.yml} eintragen \\ \hline
		Zugriff auf JavaScript & Siehe Listing \ref{listing:log-js} & Zugriffsrechte der Dateien prüfen, ggf. Zeile 8 aus \path{application.html.erb} löschen \\ \hline 
		Java NameError & NameError (cannot load Java class bcrypt\_jruby.BCrypt) & Bug in bcrypt-ruby, Version >= 2.1.4 installieren \\ \hline
		NoMethodError & Siehe Listing \ref{listing:log-no-method} & Jruby ist aktuell nur zu Ruby 1.8 kompatibel, die Klasse \emph{Dir} verfügt erst seit Ruby 1.9 über die Methode \emph{exists?}. Alternativ könnte auch ein Fehler in der Applikation vorherrschen.
	\end{tabular}
	\end{table}
	\begin{lstlisting}[style=bash, caption=Log - Fehler beim Zugriff auf JavaScript, label=listing:log-js]
ActionView::Template::Error (Permission denied - /tmp/all.js.25052.4415 or /usr/local/tomcat/webapps/Grubyware/javascripts/all.js):
    5:     <%= stylesheet_link_tag 'reset.css' %>
    6:     <%= stylesheet_link_tag 'form.css' %>
    7:     <%= stylesheet_link_tag 'grubyware.css' %>
    8:     <%= javascript_include_tag :defaults, :cache => true %>
    9:     <%= csrf_meta_tag %>
    10:   </head>
    11:   <body>
  app/views/layouts/application.html.erb:8:in `_app_views_layouts_application_html_erb__616068060_2208_0'
  app/controllers/projects_controller.rb:15:in `index'
    \end{lstlisting}
    \begin{lstlisting}[style=bash, caption=Log - unbekannte Methode, label=listing:log-no-method]
NoMethodError (undefined method `exists?' for Dir:Class):
  app/controllers/dataobjects_controller.rb:115:in `upload'
  app/controllers/dataobjects_controller.rb:113:in `upload'
    \end{lstlisting}
    
    \section{Zusammenfassung}
    Das Ziel dieses Tutorials ist es dem Leser einen Einstieg in das Ruby on Rails 3 Framework zu bieten. Dazu wird
    zu Beginn die MVC-Architektur erläutert, da Rails dieses umsetzt. Die folgende Beispielapplikation
    zeigt die Umsetzung und das ineinander Greifen der einzelnen Schichten. Nachdem die Grundlagen 
    vermittelt sind werden tiefere Einblicke in die einzelnen Bereiche einer Railsapplikation gegeben. 
    
    
    Im Kapitel Controller werden die Mechanismen zur Steuerung der Applikation erläutert. Dazu gehören das Verwalten
    von Sessions, Datei Up- und Download, Filter und nicht zuletzt das Erstellen von Methoden und Actions.\\ Im Routing
    wird erklärt wie Anfragen zu den Controllern durchgeleitet werden, und welche Actions diese ausführen. \\Das 
    Anlegen von Datenbanken, sowie das Abfragen von Daten ist die Aufgabe von Active Record. Ebenso die Validierung von Daten und das Modellieren der Beziehungen zwischen Model-Klassen. \\
    Die Präsentation der Anwendung ist Aufgabe der Action View. Sie bietet Werkzeuge, um HTML-Seiten dynamisch zu
    erzeugen, und diese untereinander zu verknüpfen. \\\\Zuletzt werden die nötigen Schritte, um ein Applikation auf einem Produktivserver zu betreiben, im Kapitel Deployment beschrieben. Hierbei wird auf mögliche Fehlerquellen eingegangen und Lösungsansätze aufgezeigt.
    	\begin{thebibliography}{999}
	\bibitem [RoR3Release] {RoR3Release} Ruby on Rails 3 Release Notes \url{http://edgeguides.rubyonrails.org/3\_0\_release\_notes.html}
	\bibitem [Ruby] {Ruby} ''Mr. Neighborly's Humble Little Ruby Book'' von Jeremy McAnally \url{http://www.humblelittlerubybook.com/book/html/index.html} 
	\bibitem [API Dokumentation] {API Dokumentation} \url{http://api.rubyonrails.org/}
	\bibitem [API FormHelper] {API FormHelper} \url{http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html}
	\bibitem [FormHelper Guide] {FormHelper Guide} \url{http://guides.rubyonrails.org/form_helpers.html}
	\bibitem [RVM-Doku] {RVM-Doku} \url{http://rvm.beginrescueend.com/rvm/install/}
	\bibitem [CookieStore] {CookieStore} \url{http://rubydoc.info/docs/rails/3.0.0/ActionDispatch/Session/CookieStore}
	\bibitem [DRbStore] {DRbStore} \url{http://guides.rubyonrails.org/caching_with_rails.html#cache-stores}
	\bibitem [MemCacheStore] {MemCacheStore} \url{http://api.rubyonrails.org/classes/ActiveSupport/Cache/MemCacheStore.html}
	\bibitem [ActiveRecordStore] {ActiveRecordStore} \url{http://apidock.com/rails/CGI/Session/ActiveRecordStore}
	\end{thebibliography}
\end{document}

